Re: Linux-Kernel Archive: No 100 HZ timer !
Hi! > /* > * Timeouts for various operations: > */ > #define WAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms */ > #ifdef CONFIG_APM > #define WAIT_READY (5*HZ) /* 5sec - some laptops are very slow */ Broken broken broken. CONFIG_APM has *nothing* to do with machine being laptop. Think ACPI, think mips handheld. You should assume 5seconds, always. -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
Hi! /* * Timeouts for various operations: */ #define WAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms */ #ifdef CONFIG_APM #define WAIT_READY (5*HZ) /* 5sec - some laptops are very slow */ Broken broken broken. CONFIG_APM has *nothing* to do with machine being laptop. Think ACPI, think mips handheld. You should assume 5seconds, always. -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
Roger Larsson wrote: > > On Thursday 12 April 2001 23:52, Andre Hedrick wrote: > > Okay but what will be used for a base for hardware that has critical > > timing issues due to the rules of the hardware? > > > > I do not care but your drives/floppy/tapes/cdroms/cdrws do: > > > > /* > > * Timeouts for various operations: > > */ > > #define WAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms > > */ #ifdef CONFIG_APM > > #define WAIT_READY (5*HZ) /* 5sec - some laptops are very > > slow */ #else > > #define WAIT_READY (3*HZ/100) /* 30msec - should be instantaneous > > */ #endif /* CONFIG_APM */ > > #define WAIT_PIDENTIFY (10*HZ) /* 10sec - should be less than 3ms (?), if > > all ATAPI CD is closed at boot */ #define WAIT_WORSTCASE (30*HZ) /* 30sec > > - worst case when spinning up */ #define WAIT_CMD(10*HZ) /* 10sec > > - maximum wait for an IRQ to happen */ #define WAIT_MIN_SLEEP (2*HZ/100) > >/* 20msec - minimum sleep time */ > > > > Give me something for HZ or a rule for getting a known base so I can have > > your storage work and not corrupt. > > > > Wouldn't it make sense to define these in real world units? > And to use that to determine requested accuracy... > > Those who wait for seconds will probably not have a problem with up to (half) > a second longer wait - or...? > Those in range of the current jiffie should be able to handle up to one > jiffie longer... > > Requesting a wait in ms gives yo ms accuracy... The POSIX standard seems to point to a "CLOCK" for this sort of thing. A "CLOCK" has a resolution. One might define CLOCK_10MS, CLOCK_1US, or CLOCK_1SEC, for example. Then the request for a delay would pass the CLOCK to use as an additional parameter. Of course, CLOCK could also wrap other characteristics of the timer. For example, the jiffies variable in the system could be described as a CLOCK which has a resolution of 10 ms and is the uptime. Another CLOCK might return something related to GMT or wall time (which, by the way, is allowed to slip around a bit relative to uptime to account for leap seconds, day light time, and even the date command). Now to make this real for the kernel we would need to define a set of CLOCKs, to meet the kernel as well as the user needs. POSIX timers requires the CLOCK construct and doesn't limit it very much. Once defined to meet the standard, it is easy to extend the definition to fix the apparent needs. It is also easy to make the definition extensible and we (the high-res-timers project http://sourceforge.net/projects/high-res-timers) intend to do so. George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
Roger Larsson wrote: On Thursday 12 April 2001 23:52, Andre Hedrick wrote: Okay but what will be used for a base for hardware that has critical timing issues due to the rules of the hardware? I do not care but your drives/floppy/tapes/cdroms/cdrws do: /* * Timeouts for various operations: */ #define WAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms */ #ifdef CONFIG_APM #define WAIT_READY (5*HZ) /* 5sec - some laptops are very slow */ #else #define WAIT_READY (3*HZ/100) /* 30msec - should be instantaneous */ #endif /* CONFIG_APM */ #define WAIT_PIDENTIFY (10*HZ) /* 10sec - should be less than 3ms (?), if all ATAPI CD is closed at boot */ #define WAIT_WORSTCASE (30*HZ) /* 30sec - worst case when spinning up */ #define WAIT_CMD(10*HZ) /* 10sec - maximum wait for an IRQ to happen */ #define WAIT_MIN_SLEEP (2*HZ/100) /* 20msec - minimum sleep time */ Give me something for HZ or a rule for getting a known base so I can have your storage work and not corrupt. Wouldn't it make sense to define these in real world units? And to use that to determine requested accuracy... Those who wait for seconds will probably not have a problem with up to (half) a second longer wait - or...? Those in range of the current jiffie should be able to handle up to one jiffie longer... Requesting a wait in ms gives yo ms accuracy... The POSIX standard seems to point to a "CLOCK" for this sort of thing. A "CLOCK" has a resolution. One might define CLOCK_10MS, CLOCK_1US, or CLOCK_1SEC, for example. Then the request for a delay would pass the CLOCK to use as an additional parameter. Of course, CLOCK could also wrap other characteristics of the timer. For example, the jiffies variable in the system could be described as a CLOCK which has a resolution of 10 ms and is the uptime. Another CLOCK might return something related to GMT or wall time (which, by the way, is allowed to slip around a bit relative to uptime to account for leap seconds, day light time, and even the date command). Now to make this real for the kernel we would need to define a set of CLOCKs, to meet the kernel as well as the user needs. POSIX timers requires the CLOCK construct and doesn't limit it very much. Once defined to meet the standard, it is easy to extend the definition to fix the apparent needs. It is also easy to make the definition extensible and we (the high-res-timers project http://sourceforge.net/projects/high-res-timers) intend to do so. George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
On Thursday 12 April 2001 23:52, Andre Hedrick wrote: > Okay but what will be used for a base for hardware that has critical > timing issues due to the rules of the hardware? > > I do not care but your drives/floppy/tapes/cdroms/cdrws do: > > /* > * Timeouts for various operations: > */ > #define WAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms > */ #ifdef CONFIG_APM > #define WAIT_READY (5*HZ) /* 5sec - some laptops are very > slow */ #else > #define WAIT_READY (3*HZ/100) /* 30msec - should be instantaneous > */ #endif /* CONFIG_APM */ > #define WAIT_PIDENTIFY (10*HZ) /* 10sec - should be less than 3ms (?), if > all ATAPI CD is closed at boot */ #define WAIT_WORSTCASE (30*HZ) /* 30sec > - worst case when spinning up */ #define WAIT_CMD(10*HZ) /* 10sec > - maximum wait for an IRQ to happen */ #define WAIT_MIN_SLEEP (2*HZ/100) >/* 20msec - minimum sleep time */ > > Give me something for HZ or a rule for getting a known base so I can have > your storage work and not corrupt. > Wouldn't it make sense to define these in real world units? And to use that to determine requested accuracy... Those who wait for seconds will probably not have a problem with up to (half) a second longer wait - or...? Those in range of the current jiffie should be able to handle up to one jiffie longer... Requesting a wait in ms gives yo ms accuracy... /RogerL -- Roger Larsson SkellefteƄ Sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
Andre Hedrick wrote: > > Okay but what will be used for a base for hardware that has critical > timing issues due to the rules of the hardware? > > I do not care but your drives/floppy/tapes/cdroms/cdrws do: > > /* > * Timeouts for various operations: > */ > #define WAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms */ > #ifdef CONFIG_APM > #define WAIT_READY (5*HZ) /* 5sec - some laptops are very slow */ > #else > #define WAIT_READY (3*HZ/100) /* 30msec - should be instantaneous */ > #endif /* CONFIG_APM */ > #define WAIT_PIDENTIFY (10*HZ) /* 10sec - should be less than 3ms (?), if all >ATAPI CD is closed at boot */ > #define WAIT_WORSTCASE (30*HZ) /* 30sec - worst case when spinning up */ > #define WAIT_CMD(10*HZ) /* 10sec - maximum wait for an IRQ to happen */ > #define WAIT_MIN_SLEEP (2*HZ/100) /* 20msec - minimum sleep time */ May I make a coding-style suggestion (which is ugly on one hand, neat on the other): #define mSec *Hz/1000 /* Convert millisecs to jiffies */ #define Sec*Hz /* Convert secs to jiffies */ #define WAIT_DRQ(50 mSec) /* spec allows up to 20ms */ #ifdef CONFIG_APM #define WAIT_READY ( 5 Sec)/* some laptops are very slow */ #else #define WAIT_READY (30 mSec) /* should be instantaneous */ #endif /* CONFIG_APM */ #define WAIT_PIDENTIFY (10 Sec)/* should be less than 3ms (?), if all ATAPI CD is closed at boot */ #define WAIT_WORSTCASE (30 Sec)/* worst case when spinning up */ #define WAIT_CMD(10 Sec)/* maximum wait for an IRQ to happen */ #define WAIT_MIN_SLEEP (20 mSec) /* minimum sleep time */ I think that this is more readable than the above original. Also note that the numbers are not really repeated in the comments. If someone changes the numbers, but not the comments, it may confuse someone quite some time before he/she notices that the number that is used is not the same as the one in the comment. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
Andre Hedrick wrote: Okay but what will be used for a base for hardware that has critical timing issues due to the rules of the hardware? I do not care but your drives/floppy/tapes/cdroms/cdrws do: /* * Timeouts for various operations: */ #define WAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms */ #ifdef CONFIG_APM #define WAIT_READY (5*HZ) /* 5sec - some laptops are very slow */ #else #define WAIT_READY (3*HZ/100) /* 30msec - should be instantaneous */ #endif /* CONFIG_APM */ #define WAIT_PIDENTIFY (10*HZ) /* 10sec - should be less than 3ms (?), if all ATAPI CD is closed at boot */ #define WAIT_WORSTCASE (30*HZ) /* 30sec - worst case when spinning up */ #define WAIT_CMD(10*HZ) /* 10sec - maximum wait for an IRQ to happen */ #define WAIT_MIN_SLEEP (2*HZ/100) /* 20msec - minimum sleep time */ May I make a coding-style suggestion (which is ugly on one hand, neat on the other): #define mSec *Hz/1000 /* Convert millisecs to jiffies */ #define Sec*Hz /* Convert secs to jiffies */ #define WAIT_DRQ(50 mSec) /* spec allows up to 20ms */ #ifdef CONFIG_APM #define WAIT_READY ( 5 Sec)/* some laptops are very slow */ #else #define WAIT_READY (30 mSec) /* should be instantaneous */ #endif /* CONFIG_APM */ #define WAIT_PIDENTIFY (10 Sec)/* should be less than 3ms (?), if all ATAPI CD is closed at boot */ #define WAIT_WORSTCASE (30 Sec)/* worst case when spinning up */ #define WAIT_CMD(10 Sec)/* maximum wait for an IRQ to happen */ #define WAIT_MIN_SLEEP (20 mSec) /* minimum sleep time */ I think that this is more readable than the above original. Also note that the numbers are not really repeated in the comments. If someone changes the numbers, but not the comments, it may confuse someone quite some time before he/she notices that the number that is used is not the same as the one in the comment. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
On Thursday 12 April 2001 23:52, Andre Hedrick wrote: Okay but what will be used for a base for hardware that has critical timing issues due to the rules of the hardware? I do not care but your drives/floppy/tapes/cdroms/cdrws do: /* * Timeouts for various operations: */ #define WAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms */ #ifdef CONFIG_APM #define WAIT_READY (5*HZ) /* 5sec - some laptops are very slow */ #else #define WAIT_READY (3*HZ/100) /* 30msec - should be instantaneous */ #endif /* CONFIG_APM */ #define WAIT_PIDENTIFY (10*HZ) /* 10sec - should be less than 3ms (?), if all ATAPI CD is closed at boot */ #define WAIT_WORSTCASE (30*HZ) /* 30sec - worst case when spinning up */ #define WAIT_CMD(10*HZ) /* 10sec - maximum wait for an IRQ to happen */ #define WAIT_MIN_SLEEP (2*HZ/100) /* 20msec - minimum sleep time */ Give me something for HZ or a rule for getting a known base so I can have your storage work and not corrupt. Wouldn't it make sense to define these in real world units? And to use that to determine requested accuracy... Those who wait for seconds will probably not have a problem with up to (half) a second longer wait - or...? Those in range of the current jiffie should be able to handle up to one jiffie longer... Requesting a wait in ms gives yo ms accuracy... /RogerL -- Roger Larsson Skellefte Sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
Mark Salisbury wrote: > > > I think it makes the most sense to keep jiffie as a simple unsigned > > int. If we leave drivers, and other code as is they can deal with > > single word (32 bit) values and get reasonable results. If we make HZ > > too high (say 10,000 to get micro second resolution) we will start > > limiting the max time we can handle, in this case to about 71.5 hours. > > (Actually 1/2 this value would start giving us trouble.) HZ only > > affects the kernel internals (the user API is either seconds/micro > > seconds or seconds/nano seconds). For those cases where we want a higer > > resolution we just add a sub jiffie component. Another way of looking > > at this is to set up HZ as the "normal" resolution. This would be the > > resolution (as it is today) of the usual API calls. Only calls to the > > POSIX 1b timers would be allowed to have higher resolution. I propose > > that we use the POSIX standard to define "CLOCKS" with various > > resolution, with the understanding that the higher resolutions will have > > higher overhead. An yet another consideration, to get high resolution > > with a reasonable maximum timer interval we will need to use two words > > in the timer. I think it makes sense to use the jiffie (i.e. 1/HZ) as > > the high order part of the timer's time. > > > > Note that all of these considerations on jiffie size hold with or with > > out a tick less system. > > inner loop, i.e. interrupt timer code should never have to convert from some > real time value into number of decrementer ticks in order to set up the next > interrupt as that requires devides (and 64 bit ones at that) in a tickless > system. A good point! If we keep jiffies and sub jiffies in the timer structure, then the sub jiffies should be in hardware defined units (i.e. what we need to directly talk to the hardware). This argues for the jiffie to be longer than the longest expected inter event interval, i.e. for it to be larger than 10 ms. Seconds and sub seconds? At least this eliminates the mpy from the high order part. I think we need to balance the units used in the time list with the needs of the list management code. It may not be a good idea to tie it too tightly to the jiffie. Thinking aloud here... Another though, if we keep a small conversion table to convert from jiffies to machine units for say the first 10 jiffies, then force an "non event" timer interrupt if needed. This would, I guess, get us back to a tick system, but with tick every 10 jiffies... Still thinking... George > > this is why any variable interval list/heap/tree/whatever should be kept in > local ticks. frequently used values can be pre-computed at boot time to > speed up certain calculations (like how many local ticks/proc quantum) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
On Fri, Apr 13, 2001 at 08:20:56AM -0400, Mark Salisbury wrote: > inner loop, i.e. interrupt timer code should never have to convert from some > real time value into number of decrementer ticks in order to set up the next > interrupt as that requires devides (and 64 bit ones at that) in a tickless > system. > > this is why any variable interval list/heap/tree/whatever should be kept in > local ticks. frequently used values can be pre-computed at boot time to > speed up certain calculations (like how many local ticks/proc quantum) What about machines without synchronized local ticks? We're going to have to end up doing conversions anyway because of drift and machines without even the same speed CPUs. A time based system using local cached values such as cycles_per_usec would better be able to handle this. Michael -- Michael A. Raymond Office: (651) 683-3434 Irix Core Kernel Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
> Great HZ always defines units of jiffies, but that is worthless if there > is not a ruleset that tells me a value to divide by to return it to a > specific quantity of time. HZ obviously. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
> I think it makes the most sense to keep jiffie as a simple unsigned > int. If we leave drivers, and other code as is they can deal with > single word (32 bit) values and get reasonable results. If we make HZ > too high (say 10,000 to get micro second resolution) we will start > limiting the max time we can handle, in this case to about 71.5 hours. > (Actually 1/2 this value would start giving us trouble.) HZ only > affects the kernel internals (the user API is either seconds/micro > seconds or seconds/nano seconds). For those cases where we want a higer > resolution we just add a sub jiffie component. Another way of looking > at this is to set up HZ as the "normal" resolution. This would be the > resolution (as it is today) of the usual API calls. Only calls to the > POSIX 1b timers would be allowed to have higher resolution. I propose > that we use the POSIX standard to define "CLOCKS" with various > resolution, with the understanding that the higher resolutions will have > higher overhead. An yet another consideration, to get high resolution > with a reasonable maximum timer interval we will need to use two words > in the timer. I think it makes sense to use the jiffie (i.e. 1/HZ) as > the high order part of the timer's time. > > Note that all of these considerations on jiffie size hold with or with > out a tick less system. inner loop, i.e. interrupt timer code should never have to convert from some real time value into number of decrementer ticks in order to set up the next interrupt as that requires devides (and 64 bit ones at that) in a tickless system. this is why any variable interval list/heap/tree/whatever should be kept in local ticks. frequently used values can be pre-computed at boot time to speed up certain calculations (like how many local ticks/proc quantum) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
On Thu, Apr 12, 2001 at 09:04:28PM -0700, Andre Hedrick wrote: > On Thu, 12 Apr 2001, george anzinger wrote: > > > Actually we could do the same thing they did for errno, i.e. > > > > #define jiffies get_jiffies() > > extern unsigned get_jiffies(void); > > > No, not really. HZ still defines the units of jiffies and most all the > > timing is still related to it. Its just that interrupts are only "set > > up" when a "real" time event is due. > > Great HZ always defines units of jiffies, but that is worthless if there > is not a ruleset that tells me a value to divide by to return it to a > specific quantity of time. It makes more sense to start migrating drivers to macros such as msec_to_jiffies(), msec_to_whatever_add_timer_wants(), etc. (Names changed to protect the innocent.) And leave HZ approximately the way it is, because that's what the code expects. A good transition is for add_timer() to be defined as #define add_timer(a) add_timer_ns(a*10/HZ) although this causes problems with timers over 4 seconds. As much as I like nanoseconds, it's probably overkill here, since one should be requesting absolute time if it's specified in nanoseconds. dave... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
"Eric W. Biederman" wrote: > > Andre Hedrick <[EMAIL PROTECTED]> writes: > > > On Thu, 12 Apr 2001, george anzinger wrote: > > > > > Actually we could do the same thing they did for errno, i.e. > > > > > > #define jiffies get_jiffies() > > > extern unsigned get_jiffies(void); > > > > > No, not really. HZ still defines the units of jiffies and most all the > > > timing is still related to it. Its just that interrupts are only "set > > > up" when a "real" time event is due. > > > > Great HZ always defines units of jiffies, but that is worthless if there > > is not a ruleset that tells me a value to divide by to return it to a > > specific quantity of time. The definition of HZ is the number of units in a second. Thus if HZ is 100 we are talking about a 10 ms jiffie. > > Actually in rearranging it. jiffies should probably be redefined as > the smallest sleep we are prepared to take. And then HZ because the > number of those smallest sleeps per second. So we might see HZ values > up in the millions but otherwise things should be pretty much as > normal. Actually I think it is more useful to define it as something like 100 for the following reasons. I think it makes the most sense to keep jiffie as a simple unsigned int. If we leave drivers, and other code as is they can deal with single word (32 bit) values and get reasonable results. If we make HZ too high (say 10,000 to get micro second resolution) we will start limiting the max time we can handle, in this case to about 71.5 hours. (Actually 1/2 this value would start giving us trouble.) HZ only affects the kernel internals (the user API is either seconds/micro seconds or seconds/nano seconds). For those cases where we want a higer resolution we just add a sub jiffie component. Another way of looking at this is to set up HZ as the "normal" resolution. This would be the resolution (as it is today) of the usual API calls. Only calls to the POSIX 1b timers would be allowed to have higher resolution. I propose that we use the POSIX standard to define "CLOCKS" with various resolution, with the understanding that the higher resolutions will have higher overhead. An yet another consideration, to get high resolution with a reasonable maximum timer interval we will need to use two words in the timer. I think it makes sense to use the jiffie (i.e. 1/HZ) as the high order part of the timer's time. Note that all of these considerations on jiffie size hold with or with out a tick less system. George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
Andre Hedrick <[EMAIL PROTECTED]> writes: > On Thu, 12 Apr 2001, george anzinger wrote: > > > Actually we could do the same thing they did for errno, i.e. > > > > #define jiffies get_jiffies() > > extern unsigned get_jiffies(void); > > > No, not really. HZ still defines the units of jiffies and most all the > > timing is still related to it. Its just that interrupts are only "set > > up" when a "real" time event is due. > > Great HZ always defines units of jiffies, but that is worthless if there > is not a ruleset that tells me a value to divide by to return it to a > specific quantity of time. Actually in rearranging it. jiffies should probably be redefined as the smallest sleep we are prepared to take. And then HZ because the number of those smallest sleeps per second. So we might see HZ values up in the millions but otherwise things should be pretty much as normal. It's an interesting question though. How large should HZ be with programmable timers. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
Andre Hedrick [EMAIL PROTECTED] writes: On Thu, 12 Apr 2001, george anzinger wrote: Actually we could do the same thing they did for errno, i.e. #define jiffies get_jiffies() extern unsigned get_jiffies(void); No, not really. HZ still defines the units of jiffies and most all the timing is still related to it. Its just that interrupts are only "set up" when a "real" time event is due. Great HZ always defines units of jiffies, but that is worthless if there is not a ruleset that tells me a value to divide by to return it to a specific quantity of time. Actually in rearranging it. jiffies should probably be redefined as the smallest sleep we are prepared to take. And then HZ because the number of those smallest sleeps per second. So we might see HZ values up in the millions but otherwise things should be pretty much as normal. It's an interesting question though. How large should HZ be with programmable timers. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
"Eric W. Biederman" wrote: Andre Hedrick [EMAIL PROTECTED] writes: On Thu, 12 Apr 2001, george anzinger wrote: Actually we could do the same thing they did for errno, i.e. #define jiffies get_jiffies() extern unsigned get_jiffies(void); No, not really. HZ still defines the units of jiffies and most all the timing is still related to it. Its just that interrupts are only "set up" when a "real" time event is due. Great HZ always defines units of jiffies, but that is worthless if there is not a ruleset that tells me a value to divide by to return it to a specific quantity of time. The definition of HZ is the number of units in a second. Thus if HZ is 100 we are talking about a 10 ms jiffie. Actually in rearranging it. jiffies should probably be redefined as the smallest sleep we are prepared to take. And then HZ because the number of those smallest sleeps per second. So we might see HZ values up in the millions but otherwise things should be pretty much as normal. Actually I think it is more useful to define it as something like 100 for the following reasons. I think it makes the most sense to keep jiffie as a simple unsigned int. If we leave drivers, and other code as is they can deal with single word (32 bit) values and get reasonable results. If we make HZ too high (say 10,000 to get micro second resolution) we will start limiting the max time we can handle, in this case to about 71.5 hours. (Actually 1/2 this value would start giving us trouble.) HZ only affects the kernel internals (the user API is either seconds/micro seconds or seconds/nano seconds). For those cases where we want a higer resolution we just add a sub jiffie component. Another way of looking at this is to set up HZ as the "normal" resolution. This would be the resolution (as it is today) of the usual API calls. Only calls to the POSIX 1b timers would be allowed to have higher resolution. I propose that we use the POSIX standard to define "CLOCKS" with various resolution, with the understanding that the higher resolutions will have higher overhead. An yet another consideration, to get high resolution with a reasonable maximum timer interval we will need to use two words in the timer. I think it makes sense to use the jiffie (i.e. 1/HZ) as the high order part of the timer's time. Note that all of these considerations on jiffie size hold with or with out a tick less system. George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
On Thu, Apr 12, 2001 at 09:04:28PM -0700, Andre Hedrick wrote: On Thu, 12 Apr 2001, george anzinger wrote: Actually we could do the same thing they did for errno, i.e. #define jiffies get_jiffies() extern unsigned get_jiffies(void); No, not really. HZ still defines the units of jiffies and most all the timing is still related to it. Its just that interrupts are only "set up" when a "real" time event is due. Great HZ always defines units of jiffies, but that is worthless if there is not a ruleset that tells me a value to divide by to return it to a specific quantity of time. It makes more sense to start migrating drivers to macros such as msec_to_jiffies(), msec_to_whatever_add_timer_wants(), etc. (Names changed to protect the innocent.) And leave HZ approximately the way it is, because that's what the code expects. A good transition is for add_timer() to be defined as #define add_timer(a) add_timer_ns(a*10/HZ) although this causes problems with timers over 4 seconds. As much as I like nanoseconds, it's probably overkill here, since one should be requesting absolute time if it's specified in nanoseconds. dave... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
I think it makes the most sense to keep jiffie as a simple unsigned int. If we leave drivers, and other code as is they can deal with single word (32 bit) values and get reasonable results. If we make HZ too high (say 10,000 to get micro second resolution) we will start limiting the max time we can handle, in this case to about 71.5 hours. (Actually 1/2 this value would start giving us trouble.) HZ only affects the kernel internals (the user API is either seconds/micro seconds or seconds/nano seconds). For those cases where we want a higer resolution we just add a sub jiffie component. Another way of looking at this is to set up HZ as the "normal" resolution. This would be the resolution (as it is today) of the usual API calls. Only calls to the POSIX 1b timers would be allowed to have higher resolution. I propose that we use the POSIX standard to define "CLOCKS" with various resolution, with the understanding that the higher resolutions will have higher overhead. An yet another consideration, to get high resolution with a reasonable maximum timer interval we will need to use two words in the timer. I think it makes sense to use the jiffie (i.e. 1/HZ) as the high order part of the timer's time. Note that all of these considerations on jiffie size hold with or with out a tick less system. inner loop, i.e. interrupt timer code should never have to convert from some real time value into number of decrementer ticks in order to set up the next interrupt as that requires devides (and 64 bit ones at that) in a tickless system. this is why any variable interval list/heap/tree/whatever should be kept in local ticks. frequently used values can be pre-computed at boot time to speed up certain calculations (like how many local ticks/proc quantum) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
Great HZ always defines units of jiffies, but that is worthless if there is not a ruleset that tells me a value to divide by to return it to a specific quantity of time. HZ obviously. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
On Fri, Apr 13, 2001 at 08:20:56AM -0400, Mark Salisbury wrote: inner loop, i.e. interrupt timer code should never have to convert from some real time value into number of decrementer ticks in order to set up the next interrupt as that requires devides (and 64 bit ones at that) in a tickless system. this is why any variable interval list/heap/tree/whatever should be kept in local ticks. frequently used values can be pre-computed at boot time to speed up certain calculations (like how many local ticks/proc quantum) What about machines without synchronized local ticks? We're going to have to end up doing conversions anyway because of drift and machines without even the same speed CPUs. A time based system using local cached values such as cycles_per_usec would better be able to handle this. Michael -- Michael A. Raymond Office: (651) 683-3434 Irix Core Kernel Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
Mark Salisbury wrote: I think it makes the most sense to keep jiffie as a simple unsigned int. If we leave drivers, and other code as is they can deal with single word (32 bit) values and get reasonable results. If we make HZ too high (say 10,000 to get micro second resolution) we will start limiting the max time we can handle, in this case to about 71.5 hours. (Actually 1/2 this value would start giving us trouble.) HZ only affects the kernel internals (the user API is either seconds/micro seconds or seconds/nano seconds). For those cases where we want a higer resolution we just add a sub jiffie component. Another way of looking at this is to set up HZ as the "normal" resolution. This would be the resolution (as it is today) of the usual API calls. Only calls to the POSIX 1b timers would be allowed to have higher resolution. I propose that we use the POSIX standard to define "CLOCKS" with various resolution, with the understanding that the higher resolutions will have higher overhead. An yet another consideration, to get high resolution with a reasonable maximum timer interval we will need to use two words in the timer. I think it makes sense to use the jiffie (i.e. 1/HZ) as the high order part of the timer's time. Note that all of these considerations on jiffie size hold with or with out a tick less system. inner loop, i.e. interrupt timer code should never have to convert from some real time value into number of decrementer ticks in order to set up the next interrupt as that requires devides (and 64 bit ones at that) in a tickless system. A good point! If we keep jiffies and sub jiffies in the timer structure, then the sub jiffies should be in hardware defined units (i.e. what we need to directly talk to the hardware). This argues for the jiffie to be longer than the longest expected inter event interval, i.e. for it to be larger than 10 ms. Seconds and sub seconds? At least this eliminates the mpy from the high order part. I think we need to balance the units used in the time list with the needs of the list management code. It may not be a good idea to tie it too tightly to the jiffie. Thinking aloud here... Another though, if we keep a small conversion table to convert from jiffies to machine units for say the first 10 jiffies, then force an "non event" timer interrupt if needed. This would, I guess, get us back to a tick system, but with tick every 10 jiffies... Still thinking... George this is why any variable interval list/heap/tree/whatever should be kept in local ticks. frequently used values can be pre-computed at boot time to speed up certain calculations (like how many local ticks/proc quantum) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
On Thu, 12 Apr 2001, george anzinger wrote: > Actually we could do the same thing they did for errno, i.e. > > #define jiffies get_jiffies() > extern unsigned get_jiffies(void); > No, not really. HZ still defines the units of jiffies and most all the > timing is still related to it. Its just that interrupts are only "set > up" when a "real" time event is due. Great HZ always defines units of jiffies, but that is worthless if there is not a ruleset that tells me a value to divide by to return it to a specific quantity of time. Cheers, Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
Andre Hedrick wrote: > > On Fri, 13 Apr 2001, Alan Cox wrote: > > > > Okay but what will be used for a base for hardware that has critical > > > timing issues due to the rules of the hardware? > > > > > #define WAIT_MIN_SLEEP (2*HZ/100) /* 20msec - minimum sleep time */ > > > > > > Give me something for HZ or a rule for getting a known base so I can have > > > your storage work and not corrupt. > > > > > > The same values would be valid with add_timer and friends regardless. Its just > > that people who do > > > > while(time_before(jiffies, started+DELAY)) > > { > > if(poll_foo()) > > break; > > } > > > > would need to either use add_timer or we could implement get_jiffies() Actually we could do the same thing they did for errno, i.e. #define jiffies get_jiffies() extern unsigned get_jiffies(void); > > Okay regardless of the call what is it going to be or do we just random > and go oh-crap data!?!? > > Since HZ!==100 of all archs that have ATA/ATAPI support, it is a mircale > that FS corruption and system death is not more rampant, except for the > fact that hardware is quick by a factor of 10+ so that 1000 does not quite > do as much harm but the associated mean of HZ changes and that is a > problem with slower hardware. No, not really. HZ still defines the units of jiffies and most all the timing is still related to it. Its just that interrupts are only "set up" when a "real" time event is due. George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
On Fri, 13 Apr 2001, Alan Cox wrote: > > Okay but what will be used for a base for hardware that has critical > > timing issues due to the rules of the hardware? > > > #define WAIT_MIN_SLEEP (2*HZ/100) /* 20msec - minimum sleep time */ > > > > Give me something for HZ or a rule for getting a known base so I can have > > your storage work and not corrupt. > > > The same values would be valid with add_timer and friends regardless. Its just > that people who do > > while(time_before(jiffies, started+DELAY)) > { > if(poll_foo()) > break; > } > > would need to either use add_timer or we could implement get_jiffies() Okay regardless of the call what is it going to be or do we just random and go oh-crap data!?!? Since HZ!==100 of all archs that have ATA/ATAPI support, it is a mircale that FS corruption and system death is not more rampant, except for the fact that hardware is quick by a factor of 10+ so that 1000 does not quite do as much harm but the associated mean of HZ changes and that is a problem with slower hardware. Nevermind just going nuts over the issues... Just trying to keep the flamage down and stuff like that Cheers, Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
> Okay but what will be used for a base for hardware that has critical > timing issues due to the rules of the hardware? > #define WAIT_MIN_SLEEP (2*HZ/100) /* 20msec - minimum sleep time */ > > Give me something for HZ or a rule for getting a known base so I can have > your storage work and not corrupt. The same values would be valid with add_timer and friends regardless. Its just that people who do while(time_before(jiffies, started+DELAY)) { if(poll_foo()) break; } would need to either use add_timer or we could implement get_jiffies() - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
Okay but what will be used for a base for hardware that has critical timing issues due to the rules of the hardware? I do not care but your drives/floppy/tapes/cdroms/cdrws do: /* * Timeouts for various operations: */ #define WAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms */ #ifdef CONFIG_APM #define WAIT_READY (5*HZ) /* 5sec - some laptops are very slow */ #else #define WAIT_READY (3*HZ/100) /* 30msec - should be instantaneous */ #endif /* CONFIG_APM */ #define WAIT_PIDENTIFY (10*HZ) /* 10sec - should be less than 3ms (?), if all ATAPI CD is closed at boot */ #define WAIT_WORSTCASE (30*HZ) /* 30sec - worst case when spinning up */ #define WAIT_CMD(10*HZ) /* 10sec - maximum wait for an IRQ to happen */ #define WAIT_MIN_SLEEP (2*HZ/100) /* 20msec - minimum sleep time */ Give me something for HZ or a rule for getting a known base so I can have your storage work and not corrupt. Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
Okay but what will be used for a base for hardware that has critical timing issues due to the rules of the hardware? I do not care but your drives/floppy/tapes/cdroms/cdrws do: /* * Timeouts for various operations: */ #define WAIT_DRQ(5*HZ/100) /* 50msec - spec allows up to 20ms */ #ifdef CONFIG_APM #define WAIT_READY (5*HZ) /* 5sec - some laptops are very slow */ #else #define WAIT_READY (3*HZ/100) /* 30msec - should be instantaneous */ #endif /* CONFIG_APM */ #define WAIT_PIDENTIFY (10*HZ) /* 10sec - should be less than 3ms (?), if all ATAPI CD is closed at boot */ #define WAIT_WORSTCASE (30*HZ) /* 30sec - worst case when spinning up */ #define WAIT_CMD(10*HZ) /* 10sec - maximum wait for an IRQ to happen */ #define WAIT_MIN_SLEEP (2*HZ/100) /* 20msec - minimum sleep time */ Give me something for HZ or a rule for getting a known base so I can have your storage work and not corrupt. Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
Okay but what will be used for a base for hardware that has critical timing issues due to the rules of the hardware? #define WAIT_MIN_SLEEP (2*HZ/100) /* 20msec - minimum sleep time */ Give me something for HZ or a rule for getting a known base so I can have your storage work and not corrupt. The same values would be valid with add_timer and friends regardless. Its just that people who do while(time_before(jiffies, started+DELAY)) { if(poll_foo()) break; } would need to either use add_timer or we could implement get_jiffies() - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
On Fri, 13 Apr 2001, Alan Cox wrote: Okay but what will be used for a base for hardware that has critical timing issues due to the rules of the hardware? #define WAIT_MIN_SLEEP (2*HZ/100) /* 20msec - minimum sleep time */ Give me something for HZ or a rule for getting a known base so I can have your storage work and not corrupt. The same values would be valid with add_timer and friends regardless. Its just that people who do while(time_before(jiffies, started+DELAY)) { if(poll_foo()) break; } would need to either use add_timer or we could implement get_jiffies() Okay regardless of the call what is it going to be or do we just random and go oh-crap data!?!? Since HZ!==100 of all archs that have ATA/ATAPI support, it is a mircale that FS corruption and system death is not more rampant, except for the fact that hardware is quick by a factor of 10+ so that 1000 does not quite do as much harm but the associated mean of HZ changes and that is a problem with slower hardware. Nevermind just going nuts over the issues... Just trying to keep the flamage down and stuff like that Cheers, Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
Andre Hedrick wrote: On Fri, 13 Apr 2001, Alan Cox wrote: Okay but what will be used for a base for hardware that has critical timing issues due to the rules of the hardware? #define WAIT_MIN_SLEEP (2*HZ/100) /* 20msec - minimum sleep time */ Give me something for HZ or a rule for getting a known base so I can have your storage work and not corrupt. The same values would be valid with add_timer and friends regardless. Its just that people who do while(time_before(jiffies, started+DELAY)) { if(poll_foo()) break; } would need to either use add_timer or we could implement get_jiffies() Actually we could do the same thing they did for errno, i.e. #define jiffies get_jiffies() extern unsigned get_jiffies(void); Okay regardless of the call what is it going to be or do we just random and go oh-crap data!?!? Since HZ!==100 of all archs that have ATA/ATAPI support, it is a mircale that FS corruption and system death is not more rampant, except for the fact that hardware is quick by a factor of 10+ so that 1000 does not quite do as much harm but the associated mean of HZ changes and that is a problem with slower hardware. No, not really. HZ still defines the units of jiffies and most all the timing is still related to it. Its just that interrupts are only "set up" when a "real" time event is due. George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
On Thu, 12 Apr 2001, george anzinger wrote: Actually we could do the same thing they did for errno, i.e. #define jiffies get_jiffies() extern unsigned get_jiffies(void); No, not really. HZ still defines the units of jiffies and most all the timing is still related to it. Its just that interrupts are only "set up" when a "real" time event is due. Great HZ always defines units of jiffies, but that is worthless if there is not a ruleset that tells me a value to divide by to return it to a specific quantity of time. Cheers, Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/