On Thu, 2005-07-14 at 16:25 -0700, Linus Torvalds wrote:
> Yes. I see absolutely no point to it until I actually hear people who have
> actually tried some real load that doesn't work. Dammit, I want a real
> user who says that he can noticeable see his DVD stuttering, not some
> theory.
>
>
On Thu, 14 Jul 2005, Linus Torvalds wrote:
>
> But what you can do is to have HZ at some reasonably high value (ie in the
> kHz range), and then slow down the system clock to conserve energy, and
> increment jiffies by 16 or 32 when in "slow clock mode".
Btw, it doesn't have to even be a
On Thu, 14 Jul 2005, Lee Revell wrote:
>
> On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
> > I have to say, this whole thread has been pretty damn worthless in
> > general in my not-so-humble opinion.
> >
>
> This thread has really gone OT, but to revisit the original issue for a
>
On Thu, 14 Jul 2005, Alan Cox wrote:
>
> I suspect the problem for some of this is that people think of jiffies
> as incrementing by 1. If HZ is right then jiffies can be in nS, it just
> won't increment by 1.
No, jiffies _cannot_ be in nS, because of the fact that then it doesn't
fit in a
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
> I have to say, this whole thread has been pretty damn worthless in
> general in my not-so-humble opinion.
>
This thread has really gone OT, but to revisit the original issue for a
bit, are you still unwilling to consider leaving the
On Thu, 14 Jul 2005, Alan Cox wrote:
>
> > just doesn't realize that the latter is a bit more complicated exactly
> > because the latter is a hell of a lot more POWERFUL. Trying to get rid of
> > jiffies for some religious reason is _stupid_.
>
> Getting rid of jiffies in its current form is
On Thu, Jul 14, 2005 at 01:41:44PM -0700, Christoph Lameter wrote:
> AFAIK John simply wants to change jiffies to count in nanoseconds
> since bootup and then call it "clock_monotonic".
Clocks and counter drift so calling it seconds would be
misleading. It would really only be good for
On Iau, 2005-07-14 at 21:13, Linus Torvalds wrote:
> There is no way to avoid having some kind of counter to specify time.
> NONE. The only choice is what you base your notion of time on, and how you
> represent it. Do you represent it as two separate counters and try to make
> it look like
> just doesn't realize that the latter is a bit more complicated exactly
> because the latter is a hell of a lot more POWERFUL. Trying to get rid of
> jiffies for some religious reason is _stupid_.
Getting rid of jiffies in its current form is a huge win for very
non-religious reasons. Jiffies
On Thu, 2005-07-14 at 13:13 -0700, Linus Torvalds wrote:
>
> On Thu, 14 Jul 2005, john stultz wrote:
> >
> > We'll I'd probably put it as: "they do care about absolute time, but
> > they do not care about ticks or timer interrupt frequency"
>
> Well, the thing is, you have to count time some
>Of course using APIC internal timers is generally the best idea on SMP,
>but they may have had reasons to avoid them (it's not an ISA interrupt,
so
>it could have been simply out of question in the initial design).
Best? No.
Local APIC timers are based on a clock which on many processors will
Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> HPETs have a fixed frequency (usually 14.31818 MHz, but that depends
> on the manufacturer).
>
>> - 64-bit "match timer" (i.e., a register in the counter which fires IRQ
>> when it matches the counter value)
>
> That's implemented in the HPET
On Thu, 14 Jul 2005, Linus Torvalds wrote:
> So the _sane_ way to do timeouts is to define an _arbitrary_ clock that is
> just an integer counter. None of this "nanoseconds + full seconds" crap.
> None of this stupid confusion with "real time". You select something that
> is conceptually
On Thu, Jul 14, 2005 Linus Torvalds wrote:
> In other words, the _right_ way to do this is literally
>
> unsigned long timeout = jiffies + HZ/2;
> for (;;) {
> if (ready())
> return 0;
> if (time_after(timeout, jiffies))
>
On Thu, Jul 14, 2005 at 01:06:00PM -0700, Linus Torvalds wrote:
> On Thu, 14 Jul 2005, Russell King wrote:
> > Umm. Except, according to your description of what it's supposed to
> > do, the above code can have an accumulating error.
>
> No. It can have a local drift, but the point is, the error
On Thu, 14 Jul 2005, john stultz wrote:
>
> We'll I'd probably put it as: "they do care about absolute time, but
> they do not care about ticks or timer interrupt frequency"
Well, the thing is, you have to count time some sane way.
You can do it by having very expensive data structures that
On Thu, 14 Jul 2005, Russell King wrote:
>
> Umm. Except, according to your description of what it's supposed to
> do, the above code can have an accumulating error.
No. It can have a local drift, but the point is, the error never gets
worse - it _stays_ local.
There's no point in polling
On Thu, 2005-07-14 at 19:02 +0200, Arjan van de Ven wrote:
> On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
> > just doesn't realize that the latter is a bit more complicated exactly
> > because the latter is a hell of a lot more POWERFUL. Trying to get rid of
> > jiffies for some
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
>
> On Thu, 14 Jul 2005, Vojtech Pavlik wrote:
> >
> > A note on the relaive timer API: There needs to be a way to say
> > "x milliseconds from the time this timer should have triggered" instead
> > of "x milliseconds from now", to avoid
On Thu, Jul 14, 2005 at 10:21:41AM -0700, Linus Torvalds wrote:
> In other words, the _right_ way to do this is literally
>
> unsigned long timeout = jiffies + HZ/2;
> for (;;) {
> if (ready())
> return 0;
> if (time_after(timeout,
On Thu, 14 Jul 2005, Jan Engelhardt wrote:
>
> >> >>> What does Windows do here?
> >> >> windows xp base rate is 100Hz... but multimedia apps can ask for almost
> >> > 83Hz
> >> Well, Windoes 98 (vmmon) shows very different ones:
> >Wow. Windows has been doing this since *98*?
>
> ...since
>> >>> What does Windows do here?
>> >> windows xp base rate is 100Hz... but multimedia apps can ask for almost
>> > 83Hz
>> Well, Windoes 98 (vmmon) shows very different ones:
>Wow. Windows has been doing this since *98*?
...since Windows does multitask scheduling I suppose, which is since 95
Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
>
> A note on the relaive timer API: There needs to be a way to say
> "x milliseconds from the time this timer should have triggered" instead
> of "x milliseconds from now", to avoid skew in timers that try to be
> strictly periodic.
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
>
> There's absolutely nothing wrong with "jiffies", and anybody who
> thinks that
>
> msleep(20);
>
> is fundamentally better than
>
> timeout = jiffies + HZ/50;
>
What's wrong with structured programming?
-
To unsubscribe
On Thu, 14 Jul 2005, Chris Friesen wrote:
>
> But if all I really want is to sleep for 20ms, what does the additional
> power actually buy me?
If you _only_ want to sleep for 20ms, it doesn't buy you anything.
But the sleep is often part of a bigger picture, where the 20ms might be
part of
On Thu, 14 Jul 2005, Arjan van de Ven wrote:
>
> I *will* argue that for relative delays in drivers, msleep() is better.
Oh, I agree.
I think we should continue the simplification of the simple stuff. If
somebody just wants to sleep a while, do it.
But if somebody is doing this because they
Linus Torvalds wrote:
There's absolutely nothing wrong with "jiffies", and anybody who thinks
that
msleep(20);
is fundamentally better than
timeout = jiffies + HZ/50;
just doesn't realize that the latter is a bit more complicated exactly
because the latter is a hell of a
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
> There should be an _absolute_ interface
I'm not arguing there shouldn't be an absolute interface. I'm arguing
that *most* uses are relative, and as such a relative interface makes
sense for those cases.
> Btw, this is exactly why the
On Thu, 14 Jul 2005, Vojtech Pavlik wrote:
>
> A note on the relaive timer API: There needs to be a way to say
> "x milliseconds from the time this timer should have triggered" instead
> of "x milliseconds from now", to avoid skew in timers that try to be
> strictly periodic.
I disagree.
On Thu, 2005-07-14 at 08:02 -0700, Christoph Lameter wrote:
> I doubt that increasing the timer frequency is the way to go to solve
> these issues. HZ should be as low as possible and we should strive for
> a tickless system.
Agreed. Most of those applications are driven by their own interrupt
On Thu, 14 Jul 2005, Lee Revell wrote:
> On Thu, 2005-07-14 at 10:38 +0200, Ingo Molnar wrote:
> > - there are real-time applications (robotic environments: fast rotating
> >tools, media and mobile/phone applications, etc.) that want 10
> >usecs precision. If such users increased HZ to
On Thu, 2005-07-14 at 10:38 +0200, Ingo Molnar wrote:
> - there are real-time applications (robotic environments: fast rotating
>tools, media and mobile/phone applications, etc.) that want 10
>usecs precision. If such users increased HZ to 100,000 or even
>1000,000, the current timer
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Wed, 13 Jul 2005, Jan Engelhardt wrote:
> >
> > No, some kernel code causes a triple-fault-and-reboot when the HZ is >=
> > 10KHz. Maybe the highest possible value is 8192 Hz, not sure.
>
> Can you post the triple-fault message? It really
On Thu, 2005-07-14 at 11:24 +0200, Jan Engelhardt wrote:
> "My expectation is if we want to beat the competition, we'll want
> the ability to go *under* 100Hz."
> >>>
> >>> What does Windows do here?
> >>
> >> windows xp base rate is 100Hz... but multimedia apps can ask for almost
> >
On Thu, Jul 14, 2005 at 12:25:40PM +0200, Krzysztof Halasa wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > And in short-term things, the timeval/jiffie conversion is likely to be a
> > _bigger_ issue than the crystal frequency conversion.
> >
> > So we should aim for a HZ value that
On Thu, Jul 14, 2005 at 09:42:18AM +0200, Arjan van de Ven wrote:
> > IOW, nothing ever sees any "variable frequency", and there's never any
> > question about what the timer tick is: the timer tick is 2kHz as far as
> > everybody is concerned. It's just that the ticks sometimes come in
> >
Linus Torvalds <[EMAIL PROTECTED]> writes:
> And in short-term things, the timeval/jiffie conversion is likely to be a
> _bigger_ issue than the crystal frequency conversion.
>
> So we should aim for a HZ value that makes it easy to convert to and from
> the standard user-space interface
On Wed, 13 Jul 2005, Benjamin LaHaise wrote:
> That's one thing I truely dislike about the current timer code. If we
> could program the RTC interrupt to come into the system as an NMI (iirc
> oprofile already has code to do this), we could get much better TSC
> interpolation since we would
On Wed, 13 Jul 2005, Lee Revell wrote:
> Did anyone else find this strange:
>
> "The RTC is used in periodic mode to provide the system profiling
> interrupt on uni-processor systems and the clock interrupt on
> multi-processor systems."
>
> We just take NR_CPUS * HZ timer interrupts per
"My expectation is if we want to beat the competition, we'll want
the ability to go *under* 100Hz."
>>>
>>> What does Windows do here?
>>
>> windows xp base rate is 100Hz... but multimedia apps can ask for almost
>
> 83Hz
Well, Windoes 98 (vmmon) shows very different ones:
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I suspect that it is impractical to reprogram the PIT on a very fine
> granularity.
yes - reprogramming the PIT can take up to 10 usecs even on recent PCs.
(in fact the cost is pretty much system-independent due to PIO.) On
modern, PIT-less
> IOW, nothing ever sees any "variable frequency", and there's never any
> question about what the timer tick is: the timer tick is 2kHz as far as
> everybody is concerned. It's just that the ticks sometimes come in
> "bunches of 20".
btw we can hide all of this a lot nicer from just about
IOW, nothing ever sees any variable frequency, and there's never any
question about what the timer tick is: the timer tick is 2kHz as far as
everybody is concerned. It's just that the ticks sometimes come in
bunches of 20.
btw we can hide all of this a lot nicer from just about the entire
* Linus Torvalds [EMAIL PROTECTED] wrote:
I suspect that it is impractical to reprogram the PIT on a very fine
granularity.
yes - reprogramming the PIT can take up to 10 usecs even on recent PCs.
(in fact the cost is pretty much system-independent due to PIO.) On
modern, PIT-less
My expectation is if we want to beat the competition, we'll want
the ability to go *under* 100Hz.
What does Windows do here?
windows xp base rate is 100Hz... but multimedia apps can ask for almost
83Hz
Well, Windoes 98 (vmmon) shows very different ones:
/dev/vmmon[4355]: host clock
On Wed, 13 Jul 2005, Lee Revell wrote:
Did anyone else find this strange:
The RTC is used in periodic mode to provide the system profiling
interrupt on uni-processor systems and the clock interrupt on
multi-processor systems.
We just take NR_CPUS * HZ timer interrupts per second, what's
On Wed, 13 Jul 2005, Benjamin LaHaise wrote:
That's one thing I truely dislike about the current timer code. If we
could program the RTC interrupt to come into the system as an NMI (iirc
oprofile already has code to do this), we could get much better TSC
interpolation since we would be
Linus Torvalds [EMAIL PROTECTED] writes:
And in short-term things, the timeval/jiffie conversion is likely to be a
_bigger_ issue than the crystal frequency conversion.
So we should aim for a HZ value that makes it easy to convert to and from
the standard user-space interface formats.
On Thu, Jul 14, 2005 at 09:42:18AM +0200, Arjan van de Ven wrote:
IOW, nothing ever sees any variable frequency, and there's never any
question about what the timer tick is: the timer tick is 2kHz as far as
everybody is concerned. It's just that the ticks sometimes come in
bunches of
On Thu, Jul 14, 2005 at 12:25:40PM +0200, Krzysztof Halasa wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
And in short-term things, the timeval/jiffie conversion is likely to be a
_bigger_ issue than the crystal frequency conversion.
So we should aim for a HZ value that makes it easy
On Thu, 2005-07-14 at 11:24 +0200, Jan Engelhardt wrote:
My expectation is if we want to beat the competition, we'll want
the ability to go *under* 100Hz.
What does Windows do here?
windows xp base rate is 100Hz... but multimedia apps can ask for almost
83Hz
Well, Windoes 98
Linus Torvalds [EMAIL PROTECTED] writes:
On Wed, 13 Jul 2005, Jan Engelhardt wrote:
No, some kernel code causes a triple-fault-and-reboot when the HZ is =
10KHz. Maybe the highest possible value is 8192 Hz, not sure.
Can you post the triple-fault message? It really shouldn't
On Thu, 14 Jul 2005, Lee Revell wrote:
On Thu, 2005-07-14 at 10:38 +0200, Ingo Molnar wrote:
- there are real-time applications (robotic environments: fast rotating
tools, media and mobile/phone applications, etc.) that want 10
usecs precision. If such users increased HZ to 100,000
On Thu, 2005-07-14 at 08:02 -0700, Christoph Lameter wrote:
I doubt that increasing the timer frequency is the way to go to solve
these issues. HZ should be as low as possible and we should strive for
a tickless system.
Agreed. Most of those applications are driven by their own interrupt
On Thu, 14 Jul 2005, Vojtech Pavlik wrote:
A note on the relaive timer API: There needs to be a way to say
x milliseconds from the time this timer should have triggered instead
of x milliseconds from now, to avoid skew in timers that try to be
strictly periodic.
I disagree.
There should
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
There should be an _absolute_ interface
I'm not arguing there shouldn't be an absolute interface. I'm arguing
that *most* uses are relative, and as such a relative interface makes
sense for those cases.
Btw, this is exactly why the
Linus Torvalds wrote:
There's absolutely nothing wrong with jiffies, and anybody who thinks
that
msleep(20);
is fundamentally better than
timeout = jiffies + HZ/50;
just doesn't realize that the latter is a bit more complicated exactly
because the latter is a hell of a lot
On Thu, 14 Jul 2005, Arjan van de Ven wrote:
I *will* argue that for relative delays in drivers, msleep() is better.
Oh, I agree.
I think we should continue the simplification of the simple stuff. If
somebody just wants to sleep a while, do it.
But if somebody is doing this because they
On Thu, 14 Jul 2005, Chris Friesen wrote:
But if all I really want is to sleep for 20ms, what does the additional
power actually buy me?
If you _only_ want to sleep for 20ms, it doesn't buy you anything.
But the sleep is often part of a bigger picture, where the 20ms might be
part of a
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
There's absolutely nothing wrong with jiffies, and anybody who
thinks that
msleep(20);
is fundamentally better than
timeout = jiffies + HZ/50;
What's wrong with structured programming?
-
To unsubscribe from this
On Thu, 14 Jul 2005, Jan Engelhardt wrote:
What does Windows do here?
windows xp base rate is 100Hz... but multimedia apps can ask for almost
83Hz
Well, Windoes 98 (vmmon) shows very different ones:
Wow. Windows has been doing this since *98*?
...since Windows does multitask
On Thu, Jul 14, 2005 at 10:21:41AM -0700, Linus Torvalds wrote:
In other words, the _right_ way to do this is literally
unsigned long timeout = jiffies + HZ/2;
for (;;) {
if (ready())
return 0;
if (time_after(timeout, jiffies))
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
On Thu, 14 Jul 2005, Vojtech Pavlik wrote:
A note on the relaive timer API: There needs to be a way to say
x milliseconds from the time this timer should have triggered instead
of x milliseconds from now, to avoid skew in timers
On Thu, 2005-07-14 at 19:02 +0200, Arjan van de Ven wrote:
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
just doesn't realize that the latter is a bit more complicated exactly
because the latter is a hell of a lot more POWERFUL. Trying to get rid of
jiffies for some religious
On Thu, 14 Jul 2005, Russell King wrote:
Umm. Except, according to your description of what it's supposed to
do, the above code can have an accumulating error.
No. It can have a local drift, but the point is, the error never gets
worse - it _stays_ local.
There's no point in polling
On Thu, 14 Jul 2005, john stultz wrote:
We'll I'd probably put it as: they do care about absolute time, but
they do not care about ticks or timer interrupt frequency
Well, the thing is, you have to count time some sane way.
You can do it by having very expensive data structures that say
On Thu, Jul 14, 2005 Linus Torvalds wrote:
In other words, the _right_ way to do this is literally
unsigned long timeout = jiffies + HZ/2;
for (;;) {
if (ready())
return 0;
if (time_after(timeout, jiffies))
On Thu, 14 Jul 2005, Linus Torvalds wrote:
So the _sane_ way to do timeouts is to define an _arbitrary_ clock that is
just an integer counter. None of this nanoseconds + full seconds crap.
None of this stupid confusion with real time. You select something that
is conceptually _clearly_
Vojtech Pavlik [EMAIL PROTECTED] writes:
HPETs have a fixed frequency (usually 14.31818 MHz, but that depends
on the manufacturer).
- 64-bit match timer (i.e., a register in the counter which fires IRQ
when it matches the counter value)
That's implemented in the HPET hardware.
Of course using APIC internal timers is generally the best idea on SMP,
but they may have had reasons to avoid them (it's not an ISA interrupt,
so
it could have been simply out of question in the initial design).
Best? No.
Local APIC timers are based on a clock which on many processors will
On Thu, 2005-07-14 at 13:13 -0700, Linus Torvalds wrote:
On Thu, 14 Jul 2005, john stultz wrote:
We'll I'd probably put it as: they do care about absolute time, but
they do not care about ticks or timer interrupt frequency
Well, the thing is, you have to count time some sane way.
just doesn't realize that the latter is a bit more complicated exactly
because the latter is a hell of a lot more POWERFUL. Trying to get rid of
jiffies for some religious reason is _stupid_.
Getting rid of jiffies in its current form is a huge win for very
non-religious reasons. Jiffies is
On Iau, 2005-07-14 at 21:13, Linus Torvalds wrote:
There is no way to avoid having some kind of counter to specify time.
NONE. The only choice is what you base your notion of time on, and how you
represent it. Do you represent it as two separate counters and try to make
it look like
On Thu, Jul 14, 2005 at 01:41:44PM -0700, Christoph Lameter wrote:
AFAIK John simply wants to change jiffies to count in nanoseconds
since bootup and then call it clock_monotonic.
Clocks and counter drift so calling it prefixseconds would be
misleading. It would really only be good for
On Thu, 14 Jul 2005, Alan Cox wrote:
just doesn't realize that the latter is a bit more complicated exactly
because the latter is a hell of a lot more POWERFUL. Trying to get rid of
jiffies for some religious reason is _stupid_.
Getting rid of jiffies in its current form is a huge
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
I have to say, this whole thread has been pretty damn worthless in
general in my not-so-humble opinion.
This thread has really gone OT, but to revisit the original issue for a
bit, are you still unwilling to consider leaving the default
On Thu, 14 Jul 2005, Alan Cox wrote:
I suspect the problem for some of this is that people think of jiffies
as incrementing by 1. If HZ is right then jiffies can be in nS, it just
won't increment by 1.
No, jiffies _cannot_ be in nS, because of the fact that then it doesn't
fit in a word
On Thu, 14 Jul 2005, Lee Revell wrote:
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
I have to say, this whole thread has been pretty damn worthless in
general in my not-so-humble opinion.
This thread has really gone OT, but to revisit the original issue for a
bit, are
On Thu, 14 Jul 2005, Linus Torvalds wrote:
But what you can do is to have HZ at some reasonably high value (ie in the
kHz range), and then slow down the system clock to conserve energy, and
increment jiffies by 16 or 32 when in slow clock mode.
Btw, it doesn't have to even be a slow-down
On Thu, 2005-07-14 at 16:25 -0700, Linus Torvalds wrote:
Yes. I see absolutely no point to it until I actually hear people who have
actually tried some real load that doesn't work. Dammit, I want a real
user who says that he can noticeable see his DVD stuttering, not some
theory.
I'm
On Thu, 2005-07-14 at 16:25 -0700, Linus Torvalds wrote:
On Thu, 14 Jul 2005, Lee Revell wrote:
This thread has really gone OT, but to revisit the original issue for a
bit, are you still unwilling to consider leaving the default HZ at 1000
for 2.6.13?
Yes. I see absolutely no point to it
On Thu, 14 Jul 2005, Lee Revell wrote:
And I'm incredibly frustrated by this insistence on hard data when it's
completely obvious to anyone who knows the first thing about MIDI that
HZ=250 will fail in situations where HZ=1000 succeeds.
Ok, guys. How many people have this MIDI thing? How
On Thu, 2005-07-14 at 16:49 -0700, Linus Torvalds wrote:
YOUR argument is nobody else matters, only I do.
MY argument is that this is a case of give and take.
I wouldn't say that. I do agree with you that HZ=1000 for everyone is
problematic, I just feel that a reasonable compromise is
On Thu, 2005-07-14 at 16:49 -0700, Linus Torvalds wrote:
On Thu, 14 Jul 2005, Lee Revell wrote:
And I'm incredibly frustrated by this insistence on hard data when it's
completely obvious to anyone who knows the first thing about MIDI that
HZ=250 will fail in situations where HZ=1000
On 7/13/05, Chris Wedgwood [EMAIL PROTECTED] wrote:
On Wed, Jul 13, 2005 at 01:48:57PM -0700, Andrew Morton wrote:
Len Brown, a year ago: The bottom line number to laptop users is
battery lifetime. Just today somebody complained to me that Windows
gets twice the battery life that Linux
On Fri, 2005-07-15 at 02:04 +0200, Jesper Juhl wrote:
While reading this thread it occoured to me that perhaps what we
really want (besides sub HZ timers) might be for the kernel to
auto-tune HZ?
Would it make sense to introduce a new config option (say
CONFIG_HZ_AUTO) that when selected
On 7/15/05, Lee Revell [EMAIL PROTECTED] wrote:
On Fri, 2005-07-15 at 02:04 +0200, Jesper Juhl wrote:
While reading this thread it occoured to me that perhaps what we
really want (besides sub HZ timers) might be for the kernel to
auto-tune HZ?
Would it make sense to introduce a new
On Thu, 14 Jul 2005, Lee Revell wrote:
I don't think this will fly because we take a big performance hit by
calculating HZ at runtime.
I think it might be an acceptable solution for a distribution that really
needed it, since it should be fairly simple. However, it's definitely not
the
On Fri, 15 Jul 2005, Jesper Juhl wrote:
Even if we only have to do it once at boot? The thought was to detect
what type of machine we are booting on, figure out what a good HZ
would be for that type of box, then set that HZ value and treat it as
a constant from that point forward.
No, it
David Lang wrote:
On Wed, 13 Jul 2005, Bill Davidsen wrote:
How serious is the 1/HZ = sane problem, and more to the point how
many programs get the HZ value with a system call as opposed to
including a header or building it in? I know some of my older
programs use header files, that was
On Thu, 2005-07-14 at 23:37 +0100, Alan Cox wrote:
In actual fact you also want to fix users of
while(time_before(foo, jiffies)) { whack(mole); }
to become
init_timeout(timeout);
timeout.expires = jiffies + n
add_timeout(timeout);
On 7/15/05, Linus Torvalds [EMAIL PROTECTED] wrote:
On Thu, 14 Jul 2005, Lee Revell wrote:
I don't think this will fly because we take a big performance hit by
calculating HZ at runtime.
I think it might be an acceptable solution for a distribution that really
needed it, since it
On Thu, 2005-07-14 at 17:24 -0700, Linus Torvalds wrote:
On Thu, 14 Jul 2005, Lee Revell wrote:
Trust me. When I say that the right thing to do is to just have a fixed
(but high) HZ value, and just changing the timer rate, I'm -right-.
I'm always right. This time I'm just even more
Linus Torvalds wrote:
On Thu, 14 Jul 2005, Lee Revell wrote:
I don't think this will fly because we take a big performance hit by
calculating HZ at runtime.
I think it might be an acceptable solution for a distribution that really
needed it, since it should be fairly simple.
On Thu, 2005-07-14 at 16:49, Linus Torvalds wrote:
On Thu, 14 Jul 2005, Lee Revell wrote:
And I'm incredibly frustrated by this insistence on hard data when it's
completely obvious to anyone who knows the first thing about MIDI that
HZ=250 will fail in situations where HZ=1000 succeeds.
Linus Torvalds wrote:
On Thu, 14 Jul 2005, Lee Revell wrote:
I don't think this will fly because we take a big performance hit by
calculating HZ at runtime.
I think it might be an acceptable solution for a distribution that really
needed it, since it should be fairly simple. However, it's
On Fri, 15 Jul 2005 09:25, Linus Torvalds wrote:
On Thu, 14 Jul 2005, Lee Revell wrote:
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
I have to say, this whole thread has been pretty damn worthless in
general in my not-so-humble opinion.
This thread has really gone OT, but
On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote:
Audio did show slightly larger max latencies but nothing that would be of
significance.
On video, maximum latencies are only slightly larger at HZ 250, all the
desired cpu was achieved, but the average latency and number of missed
On Fri, 15 Jul 2005, Lee Revell wrote:
On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote:
Audio did show slightly larger max latencies but nothing that would be of
significance.
On video, maximum latencies are only slightly larger at HZ 250, all the
desired cpu was achieved, but
On Fri, 15 Jul 2005, Jesper Juhl wrote:
It's buggy, that I know. setting kernel_hz (the new boot parameter) to
250 causes my system clock to run at something like 4-5 times normal
speed
4 times normal. You don't actually make the timer interrupt happen at
250Hz, so the timer will be
101 - 200 of 405 matches
Mail list logo
