Why HZ on i386 is 100 ?

In reply to Terje Eggestad

Quoted 15 lines · On 2002.04.16 12:29 Liam Girdwood wrote:

Quoted 1 line · BALBIR SINGH
I remember seeing somewhere unix system VII used to have HZ set to
60
Quoted 1 line
for the machines built in the 70's. I wonder if todays pentium iiis
and ivs
Quoted 3 lines
should still use HZ of 100, though their internal clock is in GHz.
I think somethings in the kernel may be tuned for the value of HZ,
these
Quoted 3 lines
things would be arch specific.
Increasing the HZ on your system should change the scheduling
behaviour,
Quoted 2 lines
it could lead to more aggresive scheduling and could affect the behaviour of the VM subsystem if scheduling happens more frequently.

Quoted 9 lines

I am
Quoted 2 lines
just guessing, I do not know.
I remember reading that a higher HZ value will make your machine more responsive, but will also mean that each running process will have a smaller CPU time slice and that the kernel will spend more CPU time scheduling at the expense of processes.

Has anyone measured this?
This shouldn't be a big problem, because some architectures use value 1024, eg. Alpha, ia-64.
And todays Intel/AMD 32-bit processors are as fast as Alpha was 1-2 years ago.

Regards,

Olaf

Terje Eggestad

2002-04-16 13:35 UTC #5 lore raw

I seem to recall from theory that the 100HZ is human dependent. Any higher and you would begin to notice delays from you input until whatever program you're talking to responds.

However in order to actually notice it you must have other programs running that uses close to 100% CPU *AT LEAST AT THE SAME OR HIGHER PRIORITY*. To test this, just running a couple of shells/script with while [true;] won't slow you down until you aggressively renice the shells/script.

THus: Setting it higher *may* improve your latency if you've other CPU intensive task going. Setting it lower will only be a boon if you have so many active processes that the kernel spend more than negligible time scheduling, thus you spend fewer cycles scheduling per sec. I don't know that *so many* is with a 1 GHz CPU is but it's very likely to be > 10. The O(1) scheduler in progress will push that even higher.

Quoted 41 lines · Olaf Fraczyk

Quoted 15 lines · On 2002.04.16 12:29 Liam Girdwood wrote:
Quoted 1 line · BALBIR SINGH
I remember seeing somewhere unix system VII used to have HZ set to
60
Quoted 1 line
for the machines built in the 70's. I wonder if todays pentium iiis
and ivs
Quoted 3 lines
should still use HZ of 100, though their internal clock is in GHz.
I think somethings in the kernel may be tuned for the value of HZ,
these
Quoted 3 lines
things would be arch specific.
Increasing the HZ on your system should change the scheduling
behaviour,
Quoted 2 lines
it could lead to more aggresive scheduling and could affect the behaviour of the VM subsystem if scheduling happens more frequently.
Quoted 9 lines
I am
Quoted 2 lines
just guessing, I do not know.
I remember reading that a higher HZ value will make your machine more responsive, but will also mean that each running process will have a smaller CPU time slice and that the kernel will spend more CPU time scheduling at the expense of processes.
Has anyone measured this?
This shouldn't be a big problem, because some architectures use value 1024, eg. Alpha, ia-64.
And todays Intel/AMD 32-bit processors are as fast as Alpha was 1-2 years ago.
Regards,
Olaf
-
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/

Signature · 10 lines

_________________________________________________________________________

Terje Eggestad                  mailto:[email protected]
Scali Scalable Linux Systems    http://www.scali.com

Olaf Helsets Vei 6              tel:    +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal                     +47 975 31 574  (MOBILE)
N-0619 Oslo                     fax:    +47 22 62 89 51
NORWAY            
_________________________________________________________________________

Alan Cox

2002-04-16 13:40 UTC #6 lore raw

Quoted 3 lines

I seem to recall from theory that the 100HZ is human dependent. Any higher and you would begin to notice delays from you input until whatever program you're talking to responds.

Ultimately its because Linus pulled that number out of a hat about ten years ago. For some workloads 1KHz is much better, for others like giant number crunching people actually drop it down to about 5..

H. Peter Anvin

2002-04-17 00:22 UTC #7 lore raw

Followup to:  <[email protected]>
By author:    Alan Cox <[email protected]>
In newsgroup: linux.dev.kernel

Quoted 9 lines

Quoted 4 lines
I seem to recall from theory that the 100HZ is human dependent. Any higher and you would begin to notice delays from you input until whatever program you're talking to responds.
Ultimately its because Linus pulled that number out of a hat about ten years ago. For some workloads 1KHz is much better, for others like giant number crunching people actually drop it down to about 5..

Hardly so. 100 Hz was standard on most commercial Unices around the time the first Linux was done...

-hpa

Signature · 3 lines

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<[email protected]>

Richard B. Johnson

2002-04-16 13:04 UTC #8 lore raw

Quoted 4 lines · BALBIR SINGH

I remember seeing somewhere unix system VII used to have HZ set to 60 for the machines built in the 70's. I wonder if todays pentium iiis and ivs should still use HZ of 100, though their internal clock is in GHz.

A different clock goes to the timer chip. It is always:

	CLOCK_TICK_RATE 1193180 Hz
unless an Elan SC-520 at which time the frequency is:
	CLOCK_TICK_RATE 1189200 Hz

(from ../include/asm/timex.h)

Quoted 8 lines

I think somethings in the kernel may be tuned for the value of HZ, these things would be arch specific.
Increasing the HZ on your system should change the scheduling behaviour, it could lead to more aggresive scheduling and could affect the behaviour of the VM subsystem if scheduling happens more frequently. I am just guessing, I do not know.

It doesn't/can't change scheduling behavior. It changes only the rate at which a CPU bound task will get the CPU taken away. It also changes the rate it which it gets it back, in a 1:1 ratio, with a net effect of nothing-gained/nothing-lost except for preemption overhead.

Quoted 3 lines

Changing though trivial would require a good look at all the code that uses HZ.

The reference to HZ seems to be correct in all the headers so changing it is trivial.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

Windows-2000/Professional isn't.

Mark Mielke

2002-04-16 13:43 UTC #9 lore raw

Quoted 3 lines · Terje Eggestad

I seem to recall from theory that the 100HZ is human dependent. Any higher and you would begin to notice delays from you input until whatever program you're talking to responds.

I suspect by "higher" you mean "each tick takes up more of a second".

As in, if the HZ is *less* than 100HZ, you would notice delays when typing, or similar.

Increasing the HZ can only improve responsiveness, however, there is a cost (mentioned by others). The cost is that the scheduler is executed more often per second. If the scheduler does the same amount of work per tick, but there are more ticks per second, the scheduler does more work overall, and the CPU is free for use by the processes less.

mark

Signature · 9 lines

[email protected]/[email protected]/[email protected] __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Terje Eggestad

2002-04-16 13:55 UTC #10 lore raw

Quoted 10 lines · Mark Mielke

Quoted 3 lines · Terje Eggestad
I seem to recall from theory that the 100HZ is human dependent. Any higher and you would begin to notice delays from you input until whatever program you're talking to responds.
I suspect by "higher" you mean "each tick takes up more of a second".
As in, if the HZ is *less* than 100HZ, you would notice delays when typing, or similar.

Quote right, my typo.

Quoted 13 lines

mark

Signature · 9 lines

[email protected]/[email protected]/[email protected] __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Signature · 10 lines

_________________________________________________________________________

Terje Eggestad                  mailto:[email protected]
Scali Scalable Linux Systems    http://www.scali.com

Olaf Helsets Vei 6              tel:    +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal                     +47 975 31 574  (MOBILE)
N-0619 Oslo                     fax:    +47 22 62 89 51
NORWAY            
_________________________________________________________________________

Rik van Riel

2002-04-16 15:32 UTC #11 lore raw

In reply to Mark Mielke

Quoted 5 lines · Mark Mielke

Increasing the HZ can only improve responsiveness, however, there is a cost (mentioned by others). The cost is that the scheduler is executed more often per second. If the scheduler does the same amount of work per tick, but there are more ticks per second, the scheduler does more work overall, and the CPU is free for use by the processes less.

Why are you discussing Linux 1.2 ?

Linux is not running the scheduler each cpu tick and hasn't done this for years.

regards,

Rik

Signature · 5 lines

	http://www.linuxsymposium.org/2002/
"You're one of those condescending OLS attendants"
"Here's a nickle kid.  Go buy yourself a real t-shirt"

http://www.surriel.com/		http://distro.conectiva.com/

Chris Friesen

2002-04-16 16:03 UTC #12 lore raw

Quoted 9 lines · Rik van Riel

Quoted 5 lines · Mark Mielke
Increasing the HZ can only improve responsiveness, however, there is a cost (mentioned by others). The cost is that the scheduler is executed more often per second. If the scheduler does the same amount of work per tick, but there are more ticks per second, the scheduler does more work overall, and the CPU is free for use by the processes less.

Quoted 4 lines

Why are you discussing Linux 1.2 ?
Linux is not running the scheduler each cpu tick and hasn't done this for years.

Very true. However it does run the timer/clock code every tick, which is still additional overhead when the tick time is reduced.

The basic idea (increased overhead at higher HZ) is sound, the details are not.

Chris

Signature · 4 lines

Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: [email protected]

Mark Mielke

2002-04-16 17:17 UTC #13 lore raw

In reply to Mark Mielke

Quoted 9 lines · Rik van Riel

Quoted 5 lines · Mark Mielke
Increasing the HZ can only improve responsiveness, however, there is a cost (mentioned by others). The cost is that the scheduler is executed more often per second. If the scheduler does the same amount of work per tick, but there are more ticks per second, the scheduler does more work overall, and the CPU is free for use by the processes less.
Why are you discussing Linux 1.2 ?
Linux is not running the scheduler each cpu tick and hasn't done this for years.

Hmm... sorry... :-) Too early in the morning...

mark

Signature · 9 lines

[email protected]/[email protected]/[email protected] __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Linus Torvalds

2002-04-16 16:29 UTC #14 lore raw

In reply to Davide Libenzi

In article <[email protected]>,

Quoted 10 lines · Olaf Fraczyk

Quoted 6 lines · On 2002.04.16 12:29 Liam Girdwood wrote:
I remember reading that a higher HZ value will make your machine more responsive, but will also mean that each running process will have a smaller CPU time slice and that the kernel will spend more CPU time scheduling at the expense of processes.
Has anyone measured this?
This shouldn't be a big problem, because some architectures use value 1024, eg. Alpha, ia-64.

On the ia-64, they do indeed use a HZ value of 1000 by default.

And I've had some Intel people grumble about it, because it apparently means that the timer tick takes anything from 2% to an extreme of 10% (!!) of the CPU time under certain loads.

Apparently the 10% is due to cache/tlb intensive loads, and as a result the interrupt handler just missing in the caches a lot, but still:
that's exactly the kind of load that you want to buy an ia64 for.

There's no point in saying that "the timer interrupt takes only 0.5% of an idle CPU", if it takes a much larger chunk out of a busy one.

So the argument that a kHz timer takes a noticeable amount of CPU power seems to be still true today - even with the "architecture of tomorrow".

Yeah, I wouldn't have believed it myself, but there it is.. You only get the gigaHz speeds if you hit in the cache - when you miss, you start crawling (everything is relative, of course: the crawl of today is a rather rapid one by 6502 standards ;)

Linus

David Mosberger

2002-04-16 16:50 UTC #15 lore raw

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · On Tue, 16 Apr 2002 16:27:12 +0000 (UTC), [email protected] (Linus…

Linus> And I've had some Intel people grumble about it, because it Linus> apparently means that the timer tick takes anything from 2% Linus> to an extreme of 10% (!!) of the CPU time under certain Linus> loads.

I'm not sure I believe this. I have had occasional cases where I wondered whether the timer tick caused significant overhead, but it always turned out to be something else. In my measurements, *user-level* profiling has the 2-10% overhead you're mentioning, but that's with a signal delivered to user level on each tick.

	--david

Davide Libenzi

2002-04-16 17:11 UTC #16 lore raw

Quoted 7 lines · David Mosberger

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · On Tue, 16 Apr 2002 16:27:12 +0000 (UTC), [email protected] (Linus…
Linus> And I've had some Intel people grumble about it, because it Linus> apparently means that the timer tick takes anything from 2% Linus> to an extreme of 10% (!!) of the CPU time under certain Linus> loads.

Quoted 5 lines

I'm not sure I believe this. I have had occasional cases where I wondered whether the timer tick caused significant overhead, but it always turned out to be something else. In my measurements, *user-level* profiling has the 2-10% overhead you're mentioning, but that's with a signal delivered to user level on each tick.

i still have pieces of paper on my desk about tests done on my dual piii where by hacking HZ to 1000 the kernel build time went from an average of 2min:30sec to an average 2min:43sec. that is pretty close to 10%

- Davide

David Mosberger

2002-04-16 17:52 UTC #17 lore raw

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Davide Libenzi

Davide> i still have pieces of paper on my desk about tests done on Davide> my dual piii where by hacking HZ to 1000 the kernel build Davide> time went from an average of 2min:30sec to an average Davide> 2min:43sec. that is pretty close to 10%

Did you keep the timeslice roughly constant?

	--david

Davide Libenzi

2002-04-16 18:02 UTC #18 lore raw

Quoted 8 lines · David Mosberger

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Davide Libenzi
Davide> i still have pieces of paper on my desk about tests done on Davide> my dual piii where by hacking HZ to 1000 the kernel build Davide> time went from an average of 2min:30sec to an average Davide> 2min:43sec. that is pretty close to 10%
Did you keep the timeslice roughly constant?

it was 2.5.1 time and it was still ruled by TICK_SCALE that made the timeslice to drop from 60ms ( 100HZ ) to 21ms ( 1000HZ ).

- Davide

David Mosberger

2002-04-17 00:49 UTC #19 lore raw

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Davide Libenzi

The last time I measured timer tick overhead on ia64 it was well below 1% of overhead. I don't really like using kernel builds as a benchmark, because there are far too many variables for the results to have any long-term or cross-platform value. But since it's popular, I did measure it quickly on a relatively slow (old) Itanium box: with 100Hz, the kernel compile was about 0.6% faster than with 1024Hz (2.4.18 UP kernel).

	--david

Robert Love

2002-04-17 00:57 UTC #20 lore raw

Quoted 3 lines · David Mosberger

But since it's popular, I did measure it quickly on a relatively slow (old) Itanium box: with 100Hz, the kernel compile was about 0.6% faster than with 1024Hz (2.4.18 UP kernel).

One question I have always had is why 1024 and not 1000 ?

Because that is what Alpha does? It seems to me there is no reason for a power-of-two timer value, and using 1024 vs 1000 just makes the math and rounding more difficult.

Robert Love

Davide Libenzi

2002-04-17 01:02 UTC #21 lore raw

Quoted 11 lines · Robert Love

Quoted 3 lines · David Mosberger
But since it's popular, I did measure it quickly on a relatively slow (old) Itanium box: with 100Hz, the kernel compile was about 0.6% faster than with 1024Hz (2.4.18 UP kernel).
One question I have always had is why 1024 and not 1000 ?
Because that is what Alpha does? It seems to me there is no reason for a power-of-two timer value, and using 1024 vs 1000 just makes the math and rounding more difficult.

maybe because of the old TICK_SCALE macro ...

- Davide

Dan Mann

2002-04-17 01:53 UTC #22 lore raw

In reply to Robert Love

Why not just try and modify the time slice scale? wouldn't this then help with what you are trying to gain, while leaving other values alone that rely on 100HZ?

Doesn't an unmodified TICK_SCALE negate most of the lowered time slice effect you'd gain from raising HZ anyway?

Seems like Ingo did a bunch of work on trying to get the "sweet spot" time slice quanta value already, and I don't think he did it with the HZ value, but I could be wrong.

And if it is Xwindows performance you are trying for, it's not the kernel (flying by the seat of my pants here). I can have crappy X performance and yet my audio never skips a beat, running at exactly the same priority as X(though my X perf problems seem to stem from multiple clients rendering on screen at the same time.;-)(No disrespect to the X developers, since it does a lot of thing very nicely :-)

Dan

Quoted 20 lines · Robert Love

Quoted 3 lines · David Mosberger
But since it's popular, I did measure it quickly on a relatively slow (old) Itanium box: with 100Hz, the kernel compile was about 0.6% faster than with 1024Hz (2.4.18 UP kernel).
One question I have always had is why 1024 and not 1000 ?
Because that is what Alpha does? It seems to me there is no reason for a power-of-two timer value, and using 1024 vs 1000 just makes the math and rounding more difficult.
Robert Love
-
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/

Davide Libenzi

2002-04-17 01:15 UTC #23 lore raw

Quoted 7 lines · David Mosberger

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Davide Libenzi
Davide> i still have pieces of paper on my desk about tests done on Davide> my dual piii where by hacking HZ to 1000 the kernel build Davide> time went from an average of 2min:30sec to an average Davide> 2min:43sec. that is pretty close to 10%

Quoted 7 lines

The last time I measured timer tick overhead on ia64 it was well below 1% of overhead. I don't really like using kernel builds as a benchmark, because there are far too many variables for the results to have any long-term or cross-platform value. But since it's popular, I did measure it quickly on a relatively slow (old) Itanium box: with 100Hz, the kernel compile was about 0.6% faster than with 1024Hz (2.4.18 UP kernel).

uhm, this is quite interesting. it's quite possible at this point that PROC_CHANGE_PENALTY put an high cs pressure in place, with terrible cache effects. pretty sadly i was not running the sampler that would have helped me to detect such behaviour.

- Davide

Ben Greear

2002-04-17 03:19 UTC #24 lore raw

Quoted 7 lines · David Mosberger

The last time I measured timer tick overhead on ia64 it was well below 1% of overhead. I don't really like using kernel builds as a benchmark, because there are far too many variables for the results to have any long-term or cross-platform value. But since it's popular, I did measure it quickly on a relatively slow (old) Itanium box: with 100Hz, the kernel compile was about 0.6% faster than with 1024Hz (2.4.18 UP kernel).

How hard would it be to tune HZ dynamically at run time, either through kernel smarts, or driven from user space by some sort of daemon or other (manual) control?

Ben

Signature · 3 lines

Ben Greear <[email protected]>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Mark Mielke

2002-04-17 05:24 UTC #25 lore raw

In reply to Linus Torvalds

Quoted 9 lines · Robert Love

Quoted 3 lines · David Mosberger
But since it's popular, I did measure it quickly on a relatively slow (old) Itanium box: with 100Hz, the kernel compile was about 0.6% faster than with 1024Hz (2.4.18 UP kernel).
One question I have always had is why 1024 and not 1000 ?
Because that is what Alpha does? It seems to me there is no reason for a power-of-two timer value, and using 1024 vs 1000 just makes the math and rounding more difficult.

Only from the perspective of time displayed to a user... :-)

Of course, that may be one of the only factors...

mark

Signature · 9 lines

[email protected]/[email protected]/[email protected] __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Linus Torvalds

2002-04-17 05:35 UTC #26 lore raw

Quoted 7 lines · Mark Mielke

Quoted 4 lines · Robert Love
Because that is what Alpha does? It seems to me there is no reason for a power-of-two timer value, and using 1024 vs 1000 just makes the math and rounding more difficult.
Only from the perspective of time displayed to a user... :-)

No, it also makes it much easier to convert to/from the standard UNIX time formats (ie "struct timeval" and "struct timespec") without any surprises, because a jiffy is exactly representable in both if you have a HZ value of 100 or 100, but not if your HZ is 1024.

Linus

Robert Love

2002-04-17 06:01 UTC #27 lore raw

Quoted 4 lines · Linus Torvalds

No, it also makes it much easier to convert to/from the standard UNIX time formats (ie "struct timeval" and "struct timespec") without any surprises, because a jiffy is exactly representable in both if you have a HZ value of 100 or 100, but not if your HZ is 1024.

Exactly - this was my issue. So what _was_ the rationale behind Alpha picking 1024 (and others following)? More importantly, can we change to 1000?

Robert Love

David Mosberger

2002-04-17 06:17 UTC #28 lore raw

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Robert Love

Robert> Exactly - this was my issue. So what _was_ the rationale Robert> behind Alpha picking 1024 (and others following)?

Picking a timer tick is a bit like picking the color of a window. Everybody has an opinion and there is no truly "right" choice. I guarantee you whatever you pick, someone will come along and say:
why not X instead?

A power-of-2 value obviously makes it easy to divide by HZ.

Robert> More importantly, can we change to 1000?

On ia64, you can make it anything you want. User-level will pick up the current value from sysconf(_SC_CLK_TCK).

	--david

[email protected]

2002-04-17 08:02 UTC #29 lore raw

In reply to Robert Love

Quoted 9 lines · In article <1019023303.1670.37.camel@phantasy> you wrote:

Quoted 4 lines · Linus Torvalds
No, it also makes it much easier to convert to/from the standard UNIX time formats (ie "struct timeval" and "struct timespec") without any surprises, because a jiffy is exactly representable in both if you have a HZ value of 100 or 100, but not if your HZ is 1024.
Exactly - this was my issue. So what _was_ the rationale behind Alpha picking 1024

I seem to remember that this was for allowing True64 unix binaries to run as well, those expect HZ to be 1024.....

Signature · 4 lines

But when you distribute the same sections as part of a whole which is a work 
based on the Program, the distribution of the whole must be on the terms of 
this License, whose permissions for other licensees extend to the entire whole,
and thus to each and every part regardless of who wrote it. [sect.2 GPL]

Matti Aarnio

2002-04-17 08:04 UTC #30 lore raw

Quoted 9 lines · Robert Love

Quoted 4 lines · Linus Torvalds
No, it also makes it much easier to convert to/from the standard UNIX time formats (ie "struct timeval" and "struct timespec") without any surprises, because a jiffy is exactly representable in both if you have a HZ value of 100 or 100, but not if your HZ is 1024.
Exactly - this was my issue. So what _was_ the rationale behind Alpha picking 1024 (and others following)? More importantly, can we change to 1000?

Alpha processors don't have full division hardware, they have to iterate it one bit at the time. They do have a flash multiplier, and a barrel-shifter. Shifts take one pipeline cycle, like to addition and substraction. Multiply takes 6-12 depending on model, but division takes 64...

Converting the tick to gettimeofday() seconds is faster when the tick is power of two.

Quoted 1 line

Robert Love

/Matti Aarnio

Albert D. Cahalan

2002-04-23 22:43 UTC #31 lore raw

Quoted 12 lines · Matti Aarnio

Quoted 10 lines · Robert Love
Quoted 4 lines · Linus Torvalds
No, it also makes it much easier to convert to/from the standard UNIX time formats (ie "struct timeval" and "struct timespec") without any surprises, because a jiffy is exactly representable in both if you have a HZ value of 100 or 100, but not if your HZ is 1024.
Exactly - this was my issue. So what _was_ the rationale behind Alpha picking 1024 (and others following)? More importantly, can we change to 1000?

Quoted 5 lines

Alpha processors don't have full division hardware, they have to iterate it one bit at the time. They do have a flash multiplier, and a barrel-shifter. Shifts take one pipeline cycle, like to addition and substraction. Multiply takes 6-12 depending on model, but division takes 64...

Division by 1000 is a UMULH followed by a right shift. So maybe it costs you one cycle more than division by 1024 would.

Martin Dalecki

2002-04-17 11:14 UTC #32 lore raw

In reply to Linus Torvalds

Quoted 9 lines · Linus Torvalds

Quoted 6 lines · Mark Mielke
Quoted 3 lines · Robert Love
Because that is what Alpha does? It seems to me there is no reason for a power-of-two timer value, and using 1024 vs 1000 just makes the math and rounding more difficult.

Quoted 7 lines

Quoted 1 line
Only from the perspective of time displayed to a user... :-)
No, it also makes it much easier to convert to/from the standard UNIX time formats (ie "struct timeval" and "struct timespec") without any surprises, because a jiffy is exactly representable in both if you have a HZ value of 100 or 100, but not if your HZ is 1024.

And infally 100HZ is (by accident) quite right on the perceptive threshold of a human, which is about 0.15 of a second :).

Helge Hafting

2002-04-17 07:55 UTC #33 lore raw

Quoted 7 lines · David Mosberger

The last time I measured timer tick overhead on ia64 it was well below 1% of overhead. I don't really like using kernel builds as a benchmark, because there are far too many variables for the results to have any long-term or cross-platform value. But since it's popular, I did measure it quickly on a relatively slow (old) Itanium box: with 100Hz, the kernel compile was about 0.6% faster than with 1024Hz (2.4.18 UP kernel).

Did you try a parallell build, with the number of processes at least 2-3 times the number of processors? Then you get more
of the cache-miss effects from switching processes, not merely the overhead of the fairly fast scheduler.

Helge Hafting

Pavel Machek

2002-04-22 16:09 UTC #34 lore raw

In reply to george anzinger

Hi!

Quoted 5 lines

Davide> i still have pieces of paper on my desk about tests done on Davide> my dual piii where by hacking HZ to 1000 the kernel build Davide> time went from an average of 2min:30sec to an average Davide> 2min:43sec. that is pretty close to 10%

Quoted 7 lines

The last time I measured timer tick overhead on ia64 it was well below 1% of overhead. I don't really like using kernel builds as a benchmark, because there are far too many variables for the results to have any long-term or cross-platform value. But since it's popular, I did measure it quickly on a relatively slow (old) Itanium box: with 100Hz, the kernel compile was about 0.6% faster than with 1024Hz (2.4.18 UP kernel).

.5% still looks like a lot to me. Good compiler optimization is .5% on average...

And think what it does with old 386sx.. Maybe time for those "tick on demand" patches?
Pavel

Signature · 2 lines

Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

John Alvord

2002-04-22 17:20 UTC #35 lore raw

Quoted 15 lines · Pavel Machek

Hi!
Quoted 5 lines
Davide> i still have pieces of paper on my desk about tests done on Davide> my dual piii where by hacking HZ to 1000 the kernel build Davide> time went from an average of 2min:30sec to an average Davide> 2min:43sec. that is pretty close to 10%
Quoted 7 lines
The last time I measured timer tick overhead on ia64 it was well below 1% of overhead. I don't really like using kernel builds as a benchmark, because there are far too many variables for the results to have any long-term or cross-platform value. But since it's popular, I did measure it quickly on a relatively slow (old) Itanium box: with 100Hz, the kernel compile was about 0.6% faster than with 1024Hz (2.4.18 UP kernel).

Quoted 5 lines

.5% still looks like a lot to me. Good compiler optimization is .5% on average...
And think what it does with old 386sx.. Maybe time for those "tick on demand" patches?

Doesn't IBM have a tickless patch.. useful when demonstrating 10,000 virtual linux machines on a single system.

john alvord

george anzinger

2002-04-22 21:53 UTC #36 lore raw

Quoted 18 lines · John Alvord

Quoted 15 lines · Pavel Machek
Hi!
Quoted 12 lines
Davide> i still have pieces of paper on my desk about tests done on Davide> my dual piii where by hacking HZ to 1000 the kernel build Davide> time went from an average of 2min:30sec to an average Davide> 2min:43sec. that is pretty close to 10%
The last time I measured timer tick overhead on ia64 it was well below 1% of overhead. I don't really like using kernel builds as a benchmark, because there are far too many variables for the results to have any long-term or cross-platform value. But since it's popular, I did measure it quickly on a relatively slow (old) Itanium box: with 100Hz, the kernel compile was about 0.6% faster than with 1024Hz (2.4.18 UP kernel).

Quoted 8 lines

Quoted 5 lines
.5% still looks like a lot to me. Good compiler optimization is .5% on average...
And think what it does with old 386sx.. Maybe time for those "tick on demand" patches?
Doesn't IBM have a tickless patch.. useful when demonstrating 10,000 virtual linux machines on a single system.

Please folks. When can we put the "tick on demand" thing to bed? If in doubt, get the patch from the high-res-timers sourceforge site (see signature for the URL) and try it. Overhead becomes higher with system load passing the ticked system at relatively light loads. Just what we want, very low overhead idle systems!

The problem is in accounting (or time slicing if you prefer) where we need to start a timer each time a task is context switched to, and stop it when the task is switched away. The overhead is purely in the set up and tear down. MOST of these never expire.

-g

Quoted 8 lines

john alvord
-
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/

Signature · 4 lines

George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Real time sched:  http://sourceforge.net/projects/rtsched/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

J.D. Bakker

2002-04-22 23:06 UTC #37 lore raw

Quoted 6 lines · george anzinger

Quoted 2 lines · John Alvord
Quoted 1 line · Pavel Machek
And think what it does with old 386sx.. Maybe time for those
"tick on demand"
Quoted 2 lines
Quoted 1 line
patches?

Quoted 8 lines

Quoted 2 lines
Doesn't IBM have a tickless patch.. useful when demonstrating 10,000
virtual linux machines on a single system.
Please folks. When can we put the "tick on demand" thing to bed? If in doubt, get the patch from the high-res-timers sourceforge site (see signature for the URL) and try it. Overhead becomes higher with system load passing the ticked system at relatively light loads. Just what we want, very low overhead idle systems!

During idle, the current monitors on our StrongARM-based low power testbed show a distinct 100Hz beat. A significant portion of idle power consumption can be attributed to the timer interrupt. IIRC the IBM LinuxWatch people came to a similar conclusion.

In some cases we definitely do want very low overhead idle systems. And of course on ARM systems context switches are relatively expensive anyway, due to the need to flush the (virtually indexed/tagged) caches.

JDB
[not that I'm proposing to inflict this on the mainline kernel]

Signature · 2 lines

LART. 250 MIPS under one Watt. Free hardware design files.
http://www.lart.tudelft.nl/

Alan Cox

2002-04-23 06:50 UTC #38 lore raw

Quoted 4 lines

The problem is in accounting (or time slicing if you prefer) where we need to start a timer each time a task is context switched to, and stop it when the task is switched away. The overhead is purely in the set up and tear down. MOST of these never expire.

Done properly on many platforms a variable tick is very very easy and also very efficient to handle. X86 is a paticular problem case because the timer is so expensive to fiddle with

Anton Blanchard

2002-04-22 23:27 UTC #39 lore raw

In reply to John Alvord

Quoted 11 lines

Please folks. When can we put the "tick on demand" thing to bed? If in doubt, get the patch from the high-res-timers sourceforge site (see signature for the URL) and try it. Overhead becomes higher with system load passing the ticked system at relatively light loads. Just what we want, very low overhead idle systems!
The problem is in accounting (or time slicing if you prefer) where we need to start a timer each time a task is context switched to, and stop it when the task is switched away. The overhead is purely in the set up and tear down. MOST of these never expire.

Did you work out where exactly the overhead was and if it was hardware specific? On ppc for example updating the timer is just a write to a cpu register.

Anton

george anzinger

2002-04-23 19:04 UTC #40 lore raw

In reply to John Alvord

Quoted 8 lines · Anton Blanchard

Quoted 8 lines
Please folks. When can we put the "tick on demand" thing to bed? If in doubt, get the patch from the high-res-timers sourceforge site (see signature for the URL) and try it. Overhead becomes higher with system load passing the ticked system at relatively light loads. Just what we want, very low overhead idle systems!

Quoted 8 lines

Quoted 4 lines
The problem is in accounting (or time slicing if you prefer) where we need to start a timer each time a task is context switched to, and stop it when the task is switched away. The overhead is purely in the set up and tear down. MOST of these never expire.
Did you work out where exactly the overhead was and if it was hardware specific? On ppc for example updating the timer is just a write to a cpu register.

It has nothing to do with hardware. The over head is putting a timer entry in the list and then removing it. Almost all timers are canceled before they expire. Even with the O(1) timer list, this takes time and when done at the context switch rate the time mounts rapidly. And we need at least one timer when we switch to a task. In the test code I only start a "slice" timer. This means that a task that wants a execution time signal may find the signal delayed by as much as a slice, but it does keep the overhead lower.

Quoted 2 lines

Anton

Signature · 4 lines

George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Real time sched:  http://sourceforge.net/projects/rtsched/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

David Mosberger

2002-04-22 17:25 UTC #41 lore raw

In reply to Pavel Machek

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Pavel Machek

Pavel> .5% still looks like a lot to me. Good compiler optimization Pavel> is .5% on average...

Umh, but those optimizations are interesting only if they're cumulative, i.e., once you've got 10 of them and they make a *total* difference of 5% (actually, I'm doubtful anyone really notices differences of 20-30% other than for benchmarking purposes... ;-).

For me, 1% is the magic threshold. If we find real apps that get a higher penalty than that, I'd either lower the HZ or see if we can tune the timer tick to be within a safe margin.

No matter what, though, higher tick rate clearly incurs somewhat higher overhead. The benefit is lower application-level response time and finer-granularity timeouts. I assume Robert has all the benchmarks to show that. ;-)

	--david

Richard B. Johnson

2002-04-16 12:30 UTC #42 lore raw

In reply to William Lee Irwin III

Quoted 10 lines · William Lee Irwin III

Quoted 8 lines · Olaf Fraczyk
Hi,
I would like to know why exactly this value was choosen. Is it safe to change it to eg. 1024? Will it break anything? What else should I change to get it working:
CLOCKS_PER_SEC?
Please CC me.
Regards,
Olaf Fraczyk

Quoted 8 lines

I tried a few times running with HZ == 1024 for some testing (or I guess just to see what happened). I didn't see any problems, even without the obscure CLOCKS_PER_SEC ELF business.
Cheers,
Bill
-

On Version 2.3.17, with a 600 MHz SMP Pentium, I set HZ to 1024 and recompiled everything. There was no apparent difference in performance or "feel".

Note that HZ represents the rate at which a CPU-bound process may get the CPU taken away. Real-world tasks are more likely to be doing I/O, thus surrendering the CPU, before this relatively long time-slice expires. I don't think you will find any difference in performance with real-world tasks. FYI, the Alpha uses 1024 simply because the timer-chip can't divide down to 100 Hz.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

Windows-2000/Professional isn't.

Bill Davidsen

2002-04-16 14:07 UTC #43 lore raw

Quoted 6 lines · Olaf Fraczyk

Hi,
I would like to know why exactly this value was choosen. Is it safe to change it to eg. 1024? Will it break anything? What else should I change to get it working:
CLOCKS_PER_SEC?
Please CC me.

I think you just want to change HZ, and can do that safely. Do note that some software may be using 100 instead of HZ, so you might get some problems there.

Think of HZ as "how often do we want to thrash the cache of CPU-bound processes." More is not necessarily better.

If you want low latency there are low latency and preempt patches. They will do more the make the system responsive than increasing HZ.

Signature · 3 lines

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

bert hubert

2002-04-16 21:35 UTC #44 lore raw

Quoted 6 lines · Olaf Fraczyk

Hi,
I would like to know why exactly this value was choosen. Is it safe to change it to eg. 1024? Will it break anything? What else should I change to get it working:
CLOCKS_PER_SEC?
Please CC me.

Your uptime wraps to zero after 49 days. I think 'top' gets confused.

Regards,

bert

Signature · 3 lines

http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

Andreas Dilger

2002-04-16 22:23 UTC #45 lore raw

Quoted 9 lines · bert hubert

Quoted 6 lines · Olaf Fraczyk
Hi,
I would like to know why exactly this value was choosen. Is it safe to change it to eg. 1024? Will it break anything? What else should I change to get it working:
CLOCKS_PER_SEC?
Please CC me.
Your uptime wraps to zero after 49 days. I think 'top' gets confused.

Trivially fixed with the existing 64-bit jiffies patches. As it is, your uptime wraps to zero after 472 days or something like that if you don't have the 64-bit jiffies patch, which is totally in the realm of possibility for Linux servers.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

Herbert Xu

2002-04-16 22:37 UTC #46 lore raw

Quoted 8 lines · Andreas Dilger

Quoted 2 lines · bert hubert
Your uptime wraps to zero after 49 days. I think 'top' gets confused.
Trivially fixed with the existing 64-bit jiffies patches. As it is, your uptime wraps to zero after 472 days or something like that if you don't have the 64-bit jiffies patch, which is totally in the realm of possibility for Linux servers.

Why are we still measuring uptime using the tick variable? Ticks != time. Surely we should be recording the boot time somewhere (probably on a file system), and then comparing that with the current time?

Signature · 4 lines

Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Andreas Dilger

2002-04-16 22:58 UTC #47 lore raw

Quoted 3 lines · Herbert Xu

Why are we still measuring uptime using the tick variable? Ticks != time. Surely we should be recording the boot time somewhere (probably on a file system), and then comparing that with the current time?

Er, because the 'tick' is a valid count of the actual time that the system has been running, while the "boot time" is totally meaningless. What if the system has no RTC, or the RTC is wrong until later in the boot sequence when it can be set by the user/ntpd? What if you pass daylight savings time? Does your uptime increase/decrease by an hour?

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

J. Dow

2002-04-17 00:35 UTC #48 lore raw

From: "Andreas Dilger" <[email protected]>

Quoted 10 lines · Herbert Xu

Quoted 3 lines
Why are we still measuring uptime using the tick variable? Ticks != time. Surely we should be recording the boot time somewhere (probably on a file system), and then comparing that with the current time?
Er, because the 'tick' is a valid count of the actual time that the system has been running, while the "boot time" is totally meaningless. What if the system has no RTC, or the RTC is wrong until later in the boot sequence when it can be set by the user/ntpd? What if you pass daylight savings time? Does your uptime increase/decrease by an hour?

Well, Andreas, it seems like a very simple thing to define the time quantum, "tick", differently from the resolution of the count reported by a call to get the tick counter value. If the latter maintains a constant resolution even if the tick time changes then all utilities should continue to work. Of course, with a tick time resolution of 10mS it gets ugly when setting up a tick time of 1mS. Ideally reporting would have an LSB of a microsecond or even a tenth microsecond while the increment might still be a hundredth or thousandth of a second. Of course, that blows anything that relies on the tick counter to smithereens, I fear.

{^_^} Joanne "I STILL want a Linux suitable for multimedia applications" Dow.
[email protected] (1mS ticks is a GREAT help for multimedia apps.)

Herbert Xu

2002-04-17 02:41 UTC #49 lore raw

Quoted 6 lines · Andreas Dilger

Er, because the 'tick' is a valid count of the actual time that the system has been running, while the "boot time" is totally meaningless. What if the system has no RTC, or the RTC is wrong until later in the boot sequence when it can be set by the user/ntpd? What if you pass daylight savings time? Does your uptime increase/decrease by an hour?

Tick is the number of timer interrupts that you've collected, which may or may not be exactly 100Hz. In fact, after 400 days of operation, the deviation from true time is likely to be above 1 hour.

Anyway, you don't need the RTC since you can always fall back to the system clock which is no worse than before. However, if you do have an accurate clock source then this is much better than using the tick.

If you use ntpd, then you can simply record the time on a server that you trust, and use the tick reading at that point in time to deduce the boot time.

Signature · 4 lines

Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Kent Borg

2002-04-17 12:44 UTC #50 lore raw

Quoted 3 lines · Herbert Xu

Why are we still measuring uptime using the tick variable? Ticks != time. Surely we should be recording the boot time somewhere (probably on a file system), and then comparing that with the current time?

It depends on the meaning of "is", er, opps, I mean: it depends on the meaning of "uptime".

The notebook I am typing on at this moment was last booted just about exactly 8 days ago (judging from the timestamp on /var/log/dmesg) but in a cat-like way it spends a lot of its time asleep and so top reports an uptime of only "4 days, 2:42".

Which is correct? I suggest that the smaller number is closer to correct because that is roughly the amount of time the system has actually spent running.

-kb, the Kent who expects this question to get more complicated as the new suspend gets more and more clever and if the kernel ever starts seriously catnapping on its own.

bert hubert

2002-04-17 08:28 UTC #51 lore raw

please merge 64-bit jiffy patches. Was Re: Why HZ on i386 is 100 ?

Quoted 4 lines · Andreas Dilger

Trivially fixed with the existing 64-bit jiffies patches. As it is, your uptime wraps to zero after 472 days or something like that if you don't have the 64-bit jiffies patch, which is totally in the realm of possibility for Linux servers.

I feel your pain

4:26am up 482 days, 10:33, 2 users, load average: 0.04, 0.02, 0.00

On a very remote server.

So can we please merge the 64-bit jiffies patches? I sometimes think that that is the main reason why alpha DOES have HZ=1024 - the jiffies there don't wrap in an embarrassing way within two months :-)

Regards,

bert

Signature · 3 lines

http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

Tim Schmielau

2002-04-17 11:06 UTC #52 lore raw

Re: please merge 64-bit jiffy patches.

Quoted 10 lines · bert hubert

I feel your pain
4:26am up 482 days, 10:33, 2 users, load average: 0.04, 0.02, 0.00
On a very remote server.
So can we please merge the 64-bit jiffies patches? I sometimes think that that is the main reason why alpha DOES have HZ=1024 - the jiffies there don't wrap in an embarrassing way within two months :-)

Rik van Riel correctly suggested to merge it in 2.5 first. I have a forward-ported version, but it has a minor locking issue on UP.

Albert Cahalan suggested to get rid of locking at all by only updating the high word from the timer interupt. I will try to code this on the weekend.

I'm sorry I had no time for lobbying the merge in the last month.

Tim

bert hubert

2002-04-17 11:12 UTC #53 lore raw

Re: please merge 64-bit jiffy patches.

In reply to bert hubert

Quoted 2 lines · Tim Schmielau

Rik van Riel correctly suggested to merge it in 2.5 first. I have a forward-ported version, but it has a minor locking issue on UP.

I think that would be right. It touches a lot of code.

Quoted 2 lines

Albert Cahalan suggested to get rid of locking at all by only updating the high word from the timer interupt. I will try to code this on the weekend.

Smart.

Quoted 1 line

I'm sorry I had no time for lobbying the merge in the last month.

Anything I can do to help, just let me know. Right now I am actually facing costs because of this issue, so I am very much in favour of saving those costs 500 days from now :-)

Regards,

bert

Signature · 3 lines

http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

Bill Davidsen

2002-04-17 12:36 UTC #54 lore raw

Re: please merge 64-bit jiffy patches.

Quoted 3 lines · bert hubert

Anything I can do to help, just let me know. Right now I am actually facing costs because of this issue, so I am very much in favour of saving those costs 500 days from now :-)

Other than a few things reporting wrong numbers, what costs do you
anticipate? I have servers in six USA states (four timezones) and I haven't seen any real ill-effect on this.

Back in the Xenix days we had servers on three continents and they were
doing critical applications. There were serious costs there, people did have to be on site for a reboot.

Signature · 3 lines

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

bert hubert

2002-04-17 12:42 UTC #55 lore raw

Re: please merge 64-bit jiffy patches.

In reply to bert hubert

Quoted 3 lines · Bill Davidsen

Other than a few things reporting wrong numbers, what costs do you
anticipate? I have servers in six USA states (four timezones) and I haven't seen any real ill-effect on this.

I have been advised by Alan to treat the jiffy wraparound as a scheduled maintenance event. I tend to trust bearded kernel hackers from Wales.

Regards,

bert

Signature · 3 lines

http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

Bill Davidsen

2002-04-17 15:00 UTC #56 lore raw

Re: please merge 64-bit jiffy patches.

Quoted 8 lines · bert hubert

Quoted 3 lines · Bill Davidsen
Other than a few things reporting wrong numbers, what costs do you
anticipate? I have servers in six USA states (four timezones) and I haven't seen any real ill-effect on this.
I have been advised by Alan to treat the jiffy wraparound as a scheduled maintenance event. I tend to trust bearded kernel hackers from Wales.

Alan has to be conservative, since he want to avoid giving potentially
damaging advice to someone. However, since you can take a reboot at your convenience and schedule a year in advance, I still don't see the great cost. If you have an app which must be up 7x24 and don't have seamless backup you have other problems more serious than timer wrap.

Signature · 3 lines

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Wakko Warner

2002-04-17 11:06 UTC #57 lore raw

Re: please merge 64-bit jiffy patches. Was Re: Why HZ on i386 is 100 ?