On Tue, 2005-07-12 at 15:22 -0700, Martin J. Bligh wrote:
--On Tuesday, July 12, 2005 16:58:44 -0400 Lee Revell [EMAIL PROTECTED]
wrote:
On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
Some sort of comprimise has to be struck for now, until we get sub-HZ
timers. I'd prefer
On Mon, Jul 11, 2005 at 05:38:05PM -0700, George Anzinger wrote:
I would like to interject an addition data point, and I will NOT be
subjective. The nature of the PIT is that it can _hit_ some frequencies
better than others. We have had complaints about repeating timers not
keeping good
On Tue, 12 Jul 2005 22:10, Vojtech Pavlik wrote:
The PIT crystal runs at 14.3181818 MHz (CGA dotclock, found on ISA, ...)
and is divided by 12 to get PIT tick rate
14.3181818 MHz / 12 = 1193182 Hz
The reality is that the crystal is usually off by 50-100 ppm from the
standard value,
On Tue, 12 Jul 2005 22:39, Con Kolivas wrote:
On Tue, 12 Jul 2005 22:10, Vojtech Pavlik wrote:
The PIT crystal runs at 14.3181818 MHz (CGA dotclock, found on ISA, ...)
and is divided by 12 to get PIT tick rate
14.3181818 MHz / 12 = 1193182 Hz
The reality is that the crystal is
On Tue, Jul 12, 2005 at 10:39:00PM +1000, Con Kolivas wrote:
On Tue, 12 Jul 2005 22:10, Vojtech Pavlik wrote:
The PIT crystal runs at 14.3181818 MHz (CGA dotclock, found on ISA, ...)
and is divided by 12 to get PIT tick rate
14.3181818 MHz / 12 = 1193182 Hz
The reality is that the
On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
Look back in the thread. It made kernel compiles about 5% faster on a
fairly large box. I think the SGI people did it originally because it
caused them even larger problems.
Right, I saw those, but you don't expect to change the
On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
Exactly what problems
*does* it cause (in visible effect, not timers are less granular).
Jittery audio/video? How much worse is it?
Yes, exactly. Say you need to deliver a frame of audio or video every
5ms. You have a rendering thread
--Lee Revell [EMAIL PROTECTED] wrote (on Tuesday, July 12, 2005 10:24:59
-0400):
On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
Exactly what problems
*does* it cause (in visible effect, not timers are less granular).
Jittery audio/video? How much worse is it?
Yes, exactly. Say
On Tue, 2005-07-12 at 07:56 -0700, Martin J. Bligh wrote:
--Lee Revell [EMAIL PROTECTED] wrote (on Tuesday, July 12, 2005 10:24:59
-0400):
On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
Exactly what problems
*does* it cause (in visible effect, not timers are less granular).
--Lee Revell [EMAIL PROTECTED] wrote (on Tuesday, July 12, 2005 11:00:02
-0400):
On Tue, 2005-07-12 at 07:56 -0700, Martin J. Bligh wrote:
--Lee Revell [EMAIL PROTECTED] wrote (on Tuesday, July 12, 2005 10:24:59
-0400):
On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
On Tue, 2005-07-12 at 08:08 -0700, Martin J. Bligh wrote:
Well, looking forward, you'll have sub-HZ timers, so none of this will
matter. Actually, looking at the above, 150 seems perfectly reasonable
to me, but 300 seems to be close enough. I'll run some numbers on both.
From your above
--Lee Revell [EMAIL PROTECTED] wrote (on Tuesday, July 12, 2005 11:10:13
-0400):
On Tue, 2005-07-12 at 08:08 -0700, Martin J. Bligh wrote:
Well, looking forward, you'll have sub-HZ timers, so none of this will
matter. Actually, looking at the above, 150 seems perfectly reasonable
to me,
The PIT crystal runs at 14.3181818 MHz (CGA dotclock, found on ISA, ...)
and is divided by 12 to get PIT tick rate
14.3181818 MHz / 12 = 1193182 Hz
The reality is that the crystal is usually off by 50-100 ppm from the
standard value, depending on temperature.
HZ
Con Kolivas wrote:
On Tue, 12 Jul 2005 22:39, Con Kolivas wrote:
On Tue, 12 Jul 2005 22:10, Vojtech Pavlik wrote:
The PIT crystal runs at 14.3181818 MHz (CGA dotclock, found on ISA, ...)
and is divided by 12 to get PIT tick rate
14.3181818 MHz / 12 = 1193182 Hz
Yes, but the
On Tue, Jul 12, 2005 at 08:57:06AM -0700, George Anzinger wrote:
The PIT crystal runs at 14.3181818 MHz (CGA dotclock, found on ISA, ...)
and is divided by 12 to get PIT tick rate
14.3181818 MHz / 12 = 1193182 Hz
Yes, but the current code uses 1193180. Wonder why that is...
Because
On Tue, 2005-07-12 at 08:26 -0700, Martin J. Bligh wrote:
The PIT crystal runs at 14.3181818 MHz (CGA dotclock, found on ISA, ...)
and is divided by 12 to get PIT tick rate
14.3181818 MHz / 12 = 1193182 Hz
The reality is that the crystal is usually off by 50-100 ppm from the
On Mon, 2005-07-11 at 17:38 -0700, George Anzinger wrote:
Martin J. Bligh wrote:
Lots of people have switched from 2.4 to 2.6 (100 Hz to 1000 Hz) with no
impact in
stability, AFAIK. (I only remember some weird warning about HZ with debian
woody's
ps).
Yes, that's called progress so no
On Tue, 2005-07-12 at 08:08 -0700, Martin J. Bligh wrote:
Well, looking forward, you'll have sub-HZ timers, so none of this will
matter. Actually, looking at the above, 150 seems perfectly reasonable
to me, but 300 seems to be close enough. I'll run some numbers on
both.
From your above
--Lee Revell <[EMAIL PROTECTED]> wrote (on Tuesday, July 12, 2005 00:13:21
-0400):
> On Mon, 2005-07-11 at 21:07 -0700, Martin J. Bligh wrote:
>>
>> --Lee Revell <[EMAIL PROTECTED]> wrote (on Monday, July 11, 2005 20:30:59
>> -0400):
>>
>> > On Mon, 2005-07-11 at 14:39 -0600, Chris Friesen
On Mon, 2005-07-11 at 21:07 -0700, Martin J. Bligh wrote:
>
> --Lee Revell <[EMAIL PROTECTED]> wrote (on Monday, July 11, 2005 20:30:59
> -0400):
>
> > On Mon, 2005-07-11 at 14:39 -0600, Chris Friesen wrote:
> >> Lee Revell wrote:
> >>
> >> > Tickless + sub HZ timers is a win for everyone, the
--Lee Revell <[EMAIL PROTECTED]> wrote (on Monday, July 11, 2005 20:30:59
-0400):
> On Mon, 2005-07-11 at 14:39 -0600, Chris Friesen wrote:
>> Lee Revell wrote:
>>
>> > Tickless + sub HZ timers is a win for everyone, the multimedia people
>> > get better latency, and the laptop people get to
On Mon, 2005-07-11 at 16:08 +0200, Arjan van de Ven wrote:
> Alan: you worked on this before, where did you end up with ?
>
The last patch i've seen is 1 year old.
http://www.ussg.iu.edu/hypermail/linux/kernel/0407.3/0643.html
Eric St-Laurent
-
To unsubscribe from this list: send the line
On Mon, Jul 11, 2005 at 02:23:08PM +0100, Alan Cox wrote:
> > > Because some machines exhibit appreciable latency in entering low power
> > > state via ACPI, and 1000Hz reduces their battery life. By about half,
> > > iirc.
> > >
> > Then the owners of such machines can use HZ=250 and leave the
> The real answer here is for the tickless patches to cleaned up to the
> point where they can be merged, and then we won't waste battery power
> entering the timer interrupt in the first place. :-)
one big step forward for that is to have a
mod_timer_relative() and add_timer_relative()
which
On Mon, 2005-07-11 at 11:38 -0700, Martin J. Bligh wrote:
> >> Lots of people have switched from 2.4 to 2.6 (100 Hz to 1000 Hz) with no
> >> impact in
> >> stability, AFAIK. (I only remember some weird warning about HZ with debian
> >> woody's
> >> ps).
> >>
> >
> > Yes, that's called
Martin J. Bligh wrote:
Lots of people have switched from 2.4 to 2.6 (100 Hz to 1000 Hz) with no impact
in
stability, AFAIK. (I only remember some weird warning about HZ with debian
woody's
ps).
Yes, that's called "progress" so no one complained. Going back is
called a "regression". People
On Mon, 2005-07-11 at 14:39 -0600, Chris Friesen wrote:
> Lee Revell wrote:
>
> > Tickless + sub HZ timers is a win for everyone, the multimedia people
> > get better latency, and the laptop people get to run longer.
>
> IIRC it's not a win for many systems. Throughput goes down due to timer
>
Lee Revell wrote:
Tickless + sub HZ timers is a win for everyone, the multimedia people
get better latency, and the laptop people get to run longer.
IIRC it's not a win for many systems. Throughput goes down due to timer
manipulation overhead.
Chris
-
To unsubscribe from this list: send
On Mon, 2005-07-11 at 11:38 -0700, Martin J. Bligh wrote:
> That's a very subjective viewpoint. Realize that this is a balancing
> act between latency and overhead ... and you're firmly only looking
> at one side of the argument, instead of taking a comprimise in the
> middle ...
>
> If I start
--On Saturday, July 09, 2005 17:25:58 -0400 Lee Revell <[EMAIL PROTECTED]>
wrote:
> On Sat, 2005-07-09 at 13:30 -0700, randy_dunlap wrote:
>> | Then the owners of such machines can use HZ=250 and leave the default
>> | alone. Why should everyone have to bear the cost?
>>
>> indeed, why
>> Lots of people have switched from 2.4 to 2.6 (100 Hz to 1000 Hz) with no
>> impact in
>> stability, AFAIK. (I only remember some weird warning about HZ with debian
>> woody's
>> ps).
>>
>
> Yes, that's called "progress" so no one complained. Going back is
> called a "regression". People
On Mon, Jul 11, 2005 at 10:05:10AM -0400, Theodore Ts'o wrote:
> The real answer here is for the tickless patches to cleaned up to
> the point where they can be merged, and then we won't waste battery
> power entering the timer interrupt in the first place. :-)
Whilst conceptually this is a
> 3) is tricky I guess, it's designed for cases that are like "I want a
> timer 1 second from now, but it's ok to be also at 1.5 seconds if that
> suits you better". Those cases are far less rare than you might think at
> first, most watchdog kind things are of this type. This accuracy thing
>
> > Because some machines exhibit appreciable latency in entering low power
> > state via ACPI, and 1000Hz reduces their battery life. By about half,
> > iirc.
> >
> Then the owners of such machines can use HZ=250 and leave the default
> alone. Why should everyone have to bear the cost?
They
On Gwe, 2005-07-08 at 22:59, Andrew Morton wrote:
> Chris Wedgwood <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
> ^^
>
> It's been over two weeks and nobody has complained about anything.
Then your mail system is
On Gwe, 2005-07-08 at 22:59, Andrew Morton wrote:
Chris Wedgwood [EMAIL PROTECTED] wrote:
On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
^^
It's been over two weeks and nobody has complained about anything.
Then your mail system is faulty because
Because some machines exhibit appreciable latency in entering low power
state via ACPI, and 1000Hz reduces their battery life. By about half,
iirc.
Then the owners of such machines can use HZ=250 and leave the default
alone. Why should everyone have to bear the cost?
They need 100
3) is tricky I guess, it's designed for cases that are like I want a
timer 1 second from now, but it's ok to be also at 1.5 seconds if that
suits you better. Those cases are far less rare than you might think at
first, most watchdog kind things are of this type. This accuracy thing
will allow
On Mon, Jul 11, 2005 at 10:05:10AM -0400, Theodore Ts'o wrote:
The real answer here is for the tickless patches to cleaned up to
the point where they can be merged, and then we won't waste battery
power entering the timer interrupt in the first place. :-)
Whilst conceptually this is a nice
Lots of people have switched from 2.4 to 2.6 (100 Hz to 1000 Hz) with no
impact in
stability, AFAIK. (I only remember some weird warning about HZ with debian
woody's
ps).
Yes, that's called progress so no one complained. Going back is
called a regression. People don't like those as
--On Saturday, July 09, 2005 17:25:58 -0400 Lee Revell [EMAIL PROTECTED]
wrote:
On Sat, 2005-07-09 at 13:30 -0700, randy_dunlap wrote:
| Then the owners of such machines can use HZ=250 and leave the default
| alone. Why should everyone have to bear the cost?
indeed, why should everyone
On Mon, 2005-07-11 at 11:38 -0700, Martin J. Bligh wrote:
That's a very subjective viewpoint. Realize that this is a balancing
act between latency and overhead ... and you're firmly only looking
at one side of the argument, instead of taking a comprimise in the
middle ...
If I start arguing
Lee Revell wrote:
Tickless + sub HZ timers is a win for everyone, the multimedia people
get better latency, and the laptop people get to run longer.
IIRC it's not a win for many systems. Throughput goes down due to timer
manipulation overhead.
Chris
-
To unsubscribe from this list: send
On Mon, 2005-07-11 at 14:39 -0600, Chris Friesen wrote:
Lee Revell wrote:
Tickless + sub HZ timers is a win for everyone, the multimedia people
get better latency, and the laptop people get to run longer.
IIRC it's not a win for many systems. Throughput goes down due to timer
Martin J. Bligh wrote:
Lots of people have switched from 2.4 to 2.6 (100 Hz to 1000 Hz) with no impact
in
stability, AFAIK. (I only remember some weird warning about HZ with debian
woody's
ps).
Yes, that's called progress so no one complained. Going back is
called a regression. People
On Mon, 2005-07-11 at 11:38 -0700, Martin J. Bligh wrote:
Lots of people have switched from 2.4 to 2.6 (100 Hz to 1000 Hz) with no
impact in
stability, AFAIK. (I only remember some weird warning about HZ with debian
woody's
ps).
Yes, that's called progress so no one complained.
The real answer here is for the tickless patches to cleaned up to the
point where they can be merged, and then we won't waste battery power
entering the timer interrupt in the first place. :-)
one big step forward for that is to have a
mod_timer_relative() and add_timer_relative()
which
On Mon, Jul 11, 2005 at 02:23:08PM +0100, Alan Cox wrote:
Because some machines exhibit appreciable latency in entering low power
state via ACPI, and 1000Hz reduces their battery life. By about half,
iirc.
Then the owners of such machines can use HZ=250 and leave the default
On Mon, 2005-07-11 at 16:08 +0200, Arjan van de Ven wrote:
Alan: you worked on this before, where did you end up with ?
The last patch i've seen is 1 year old.
http://www.ussg.iu.edu/hypermail/linux/kernel/0407.3/0643.html
Eric St-Laurent
-
To unsubscribe from this list: send the line
--Lee Revell [EMAIL PROTECTED] wrote (on Monday, July 11, 2005 20:30:59
-0400):
On Mon, 2005-07-11 at 14:39 -0600, Chris Friesen wrote:
Lee Revell wrote:
Tickless + sub HZ timers is a win for everyone, the multimedia people
get better latency, and the laptop people get to run longer.
On Mon, 2005-07-11 at 21:07 -0700, Martin J. Bligh wrote:
--Lee Revell [EMAIL PROTECTED] wrote (on Monday, July 11, 2005 20:30:59
-0400):
On Mon, 2005-07-11 at 14:39 -0600, Chris Friesen wrote:
Lee Revell wrote:
Tickless + sub HZ timers is a win for everyone, the multimedia people
--Lee Revell [EMAIL PROTECTED] wrote (on Tuesday, July 12, 2005 00:13:21
-0400):
On Mon, 2005-07-11 at 21:07 -0700, Martin J. Bligh wrote:
--Lee Revell [EMAIL PROTECTED] wrote (on Monday, July 11, 2005 20:30:59
-0400):
On Mon, 2005-07-11 at 14:39 -0600, Chris Friesen wrote:
Lee
On Saturday 09 July 2005 01:08, Linus Torvalds wrote:
>
> On Fri, 8 Jul 2005, Andrew Morton wrote:
> > >
> > > The previous value here i386 is 1000 --- so why is the default 250.
> >
> > Because 1000 is too high.
>
> Yes. I chose 1000 originally partly as a way to make sure that people that
>
On Saturday 09 July 2005 01:08, Linus Torvalds wrote:
On Fri, 8 Jul 2005, Andrew Morton wrote:
The previous value here i386 is 1000 --- so why is the default 250.
Because 1000 is too high.
Yes. I chose 1000 originally partly as a way to make sure that people that
assumed HZ was
Quoting Arjan van de Ven <[EMAIL PROTECTED]>:
> [...]
> it's a config option. Some distros ship 100 already, others 1000, again
> others will do 250. What does it matter?
> (Although I still prefer 300 over 250 due to the 50/60 thing)
I just want to point out that while a frequency of 300Hz has
Lee Revell said:
> On Sat, 2005-07-09 at 13:30 -0700, randy_dunlap wrote:
>> | Then the owners of such machines can use HZ=250 and leave the default
>> | alone. Why should everyone have to bear the cost?
>>
>> indeed, why should everyone have to have 1000 timer interrupts per
>> second?
>
> So
On Sat, 2005-07-09 at 13:30 -0700, randy_dunlap wrote:
> | Then the owners of such machines can use HZ=250 and leave the default
> | alone. Why should everyone have to bear the cost?
>
> indeed, why should everyone have to have 1000 timer interrupts per second?
So why waste everyone's time with
On Sat, 09 Jul 2005 15:16:01 -0400 Lee Revell wrote:
| On Sat, 2005-07-09 at 12:12 -0700, Andrew Morton wrote:
| > Lee Revell <[EMAIL PROTECTED]> wrote:
| > >
| > > > This is not a userspace visible thing really with few exceptions, and
| > > > well people can select the one they want, right?
|
On Sat, 2005-07-09 at 12:12 -0700, Andrew Morton wrote:
> Lee Revell <[EMAIL PROTECTED]> wrote:
> >
> > > This is not a userspace visible thing really with few exceptions, and
> > > well people can select the one they want, right?
> >
> > Then why not leave the default at 1000?
>
> Because
Lee Revell <[EMAIL PROTECTED]> wrote:
>
> > This is not a userspace visible thing really with few exceptions, and
> > well people can select the one they want, right?
>
> Then why not leave the default at 1000?
Because some machines exhibit appreciable latency in entering low power
state via
On Sat, Jul 09, 2005 at 02:49:43PM -0400, Lee Revell wrote:
> BTW, Christoph Lameter, if you're seeing this, your mail is bouncing...
my bad, i typoed it when i first send the original email
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Sat, 2005-07-09 at 14:41 -0400, Lee Revell wrote:
> Yes, that's called "progress" so no one complained. Going back is
> called a "regression". People don't like those as much.
Sorry for the tone of this message, I really sound like a jerk.
Anyway, I've said all I have on this topic. I
On Sat, 2005-07-09 at 20:39 +0200, Diego Calleja wrote:
> El Sat, 09 Jul 2005 14:16:31 -0400,
> Lee Revell <[EMAIL PROTECTED]> escribió:
>
> > I still think you're absolutely insane to change the default in the
> > middle of a stable kernel series. People WILL complain about it.
>
>
> Lots of
El Sat, 09 Jul 2005 14:16:31 -0400,
Lee Revell <[EMAIL PROTECTED]> escribió:
> I still think you're absolutely insane to change the default in the
> middle of a stable kernel series. People WILL complain about it.
Lots of people have switched from 2.4 to 2.6 (100 Hz to 1000 Hz) with no impact
On Sat, 2005-07-09 at 20:31 +0200, Arjan van de Ven wrote:
> why?
Because the minimum poll/select timeout is now 4ms rather than 1ms. An
app that has a soft RT constraint somewhere in the middle that worked on
2.6.12 will break on 2.6.13.
> it's a config option. Some distros ship 100 already,
On Sat, Jul 09, 2005 at 08:31:55PM +0200, Arjan van de Ven wrote:
> it's a config option. Some distros ship 100 already, others 1000,
> again others will do 250.
Who does anything other than 1000 for a 2.6.x kernel?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Sat, 2005-07-09 at 14:16 -0400, Lee Revell wrote:
> On Sat, 2005-07-09 at 19:08 +0200, Martin Schlemmer wrote:
> > On Fri, 2005-07-08 at 14:59 -0700, Andrew Morton wrote:
> > > Chris Wedgwood <[EMAIL PROTECTED]> wrote:
> >
> > > > WHAT?
> > > >
> > > > The previous value here i386 is 1000 ---
On Sat, 2005-07-09 at 19:08 +0200, Martin Schlemmer wrote:
> On Fri, 2005-07-08 at 14:59 -0700, Andrew Morton wrote:
> > Chris Wedgwood <[EMAIL PROTECTED]> wrote:
>
> > > WHAT?
> > >
> > > The previous value here i386 is 1000 --- so why is the default 250.
> >
> > Because 1000 is too high.
> >
On Fri, 2005-07-08 at 14:59 -0700, Andrew Morton wrote:
> Chris Wedgwood <[EMAIL PROTECTED]> wrote:
> > WHAT?
> >
> > The previous value here i386 is 1000 --- so why is the default 250.
>
> Because 1000 is too high.
>
What happened to 300 as default, as that is divisible by both 50 and 60
(or
On Fri, 2005-07-08 at 14:59 -0700, Andrew Morton wrote:
Chris Wedgwood [EMAIL PROTECTED] wrote:
WHAT?
The previous value here i386 is 1000 --- so why is the default 250.
Because 1000 is too high.
What happened to 300 as default, as that is divisible by both 50 and 60
(or something
On Sat, 2005-07-09 at 19:08 +0200, Martin Schlemmer wrote:
On Fri, 2005-07-08 at 14:59 -0700, Andrew Morton wrote:
Chris Wedgwood [EMAIL PROTECTED] wrote:
WHAT?
The previous value here i386 is 1000 --- so why is the default 250.
Because 1000 is too high.
What happened to
On Sat, 2005-07-09 at 14:16 -0400, Lee Revell wrote:
On Sat, 2005-07-09 at 19:08 +0200, Martin Schlemmer wrote:
On Fri, 2005-07-08 at 14:59 -0700, Andrew Morton wrote:
Chris Wedgwood [EMAIL PROTECTED] wrote:
WHAT?
The previous value here i386 is 1000 --- so why is the default
On Sat, Jul 09, 2005 at 08:31:55PM +0200, Arjan van de Ven wrote:
it's a config option. Some distros ship 100 already, others 1000,
again others will do 250.
Who does anything other than 1000 for a 2.6.x kernel?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Sat, 2005-07-09 at 20:31 +0200, Arjan van de Ven wrote:
why?
Because the minimum poll/select timeout is now 4ms rather than 1ms. An
app that has a soft RT constraint somewhere in the middle that worked on
2.6.12 will break on 2.6.13.
it's a config option. Some distros ship 100 already,
El Sat, 09 Jul 2005 14:16:31 -0400,
Lee Revell [EMAIL PROTECTED] escribió:
I still think you're absolutely insane to change the default in the
middle of a stable kernel series. People WILL complain about it.
Lots of people have switched from 2.4 to 2.6 (100 Hz to 1000 Hz) with no impact
in
On Sat, 2005-07-09 at 20:39 +0200, Diego Calleja wrote:
El Sat, 09 Jul 2005 14:16:31 -0400,
Lee Revell [EMAIL PROTECTED] escribió:
I still think you're absolutely insane to change the default in the
middle of a stable kernel series. People WILL complain about it.
Lots of people have
On Sat, 2005-07-09 at 14:41 -0400, Lee Revell wrote:
Yes, that's called progress so no one complained. Going back is
called a regression. People don't like those as much.
Sorry for the tone of this message, I really sound like a jerk.
Anyway, I've said all I have on this topic. I don't want
On Sat, Jul 09, 2005 at 02:49:43PM -0400, Lee Revell wrote:
BTW, Christoph Lameter, if you're seeing this, your mail is bouncing...
my bad, i typoed it when i first send the original email
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Lee Revell [EMAIL PROTECTED] wrote:
This is not a userspace visible thing really with few exceptions, and
well people can select the one they want, right?
Then why not leave the default at 1000?
Because some machines exhibit appreciable latency in entering low power
state via ACPI, and
On Sat, 2005-07-09 at 12:12 -0700, Andrew Morton wrote:
Lee Revell [EMAIL PROTECTED] wrote:
This is not a userspace visible thing really with few exceptions, and
well people can select the one they want, right?
Then why not leave the default at 1000?
Because some machines
On Sat, 09 Jul 2005 15:16:01 -0400 Lee Revell wrote:
| On Sat, 2005-07-09 at 12:12 -0700, Andrew Morton wrote:
| Lee Revell [EMAIL PROTECTED] wrote:
|
| This is not a userspace visible thing really with few exceptions, and
| well people can select the one they want, right?
|
|
On Sat, 2005-07-09 at 13:30 -0700, randy_dunlap wrote:
| Then the owners of such machines can use HZ=250 and leave the default
| alone. Why should everyone have to bear the cost?
indeed, why should everyone have to have 1000 timer interrupts per second?
So why waste everyone's time with
Lee Revell said:
On Sat, 2005-07-09 at 13:30 -0700, randy_dunlap wrote:
| Then the owners of such machines can use HZ=250 and leave the default
| alone. Why should everyone have to bear the cost?
indeed, why should everyone have to have 1000 timer interrupts per
second?
So why waste
Quoting Arjan van de Ven [EMAIL PROTECTED]:
[...]
it's a config option. Some distros ship 100 already, others 1000, again
others will do 250. What does it matter?
(Although I still prefer 300 over 250 due to the 50/60 thing)
I just want to point out that while a frequency of 300Hz has good
On Fri, 2005-07-08 at 16:29 -0700, David S. Miller wrote:
> From: "Martin J. Bligh" <[EMAIL PROTECTED]>
> Date: Fri, 08 Jul 2005 16:14:59 -0700
>
> > I'm not saying there isn't data supporting higher HZ ... I just haven't
> > seen it published. I get the feeling what people really want is
From: "Martin J. Bligh" <[EMAIL PROTECTED]>
Date: Fri, 08 Jul 2005 16:14:59 -0700
> I'm not saying there isn't data supporting higher HZ ... I just haven't
> seen it published. I get the feeling what people really want is high-res
> timers anyway ... high HZ is just concealing the issue and
--On Friday, July 08, 2005 16:03:03 -0700 Chris Wedgwood <[EMAIL PROTECTED]>
wrote:
> On Fri, Jul 08, 2005 at 03:59:35PM -0700, Martin J. Bligh wrote:
>
>> I think we're talking between 2.6.12-git5 and 2.6.12-git6 right? I
>> can confirm more explicitly if really need be. 48s -> 45.5s
On Fri, Jul 08, 2005 at 03:59:35PM -0700, Martin J. Bligh wrote:
> I think we're talking between 2.6.12-git5 and 2.6.12-git6 right? I
> can confirm more explicitly if really need be. 48s -> 45.5s elapsed.
That's a huge difference (5%) --- what hardware is that on?
-
To unsubscribe from this
> It's been over two weeks and nobody has complained about anything.
>
>>
>> > [PATCH] i386: Selectable Frequency of the Timer Interrupt
>>
>> [...]
>>
>> > +choice
>> > + prompt "Timer frequency"
>> > + default HZ_250
>>
>> WHAT?
>>
>> The previous value here i386 is 1000 --- so why is
Lee Revell <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2005-07-08 at 14:59 -0700, Andrew Morton wrote:
> > Chris Wedgwood <[EMAIL PROTECTED]> wrote:
> > >
> > > On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
> > ^^
> >
> > It's been over two weeks and nobody
On Fri, 2005-07-08 at 14:59 -0700, Andrew Morton wrote:
> Chris Wedgwood <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
> ^^
>
> It's been over two weeks and nobody has complained about anything.
Wrong, I complained
On Fri, 8 Jul 2005, Andrew Morton wrote:
> >
> > The previous value here i386 is 1000 --- so why is the default 250.
>
> Because 1000 is too high.
Yes. I chose 1000 originally partly as a way to make sure that people that
assumed HZ was 100 would get a swift kick in the pants. That meant
On Fri, Jul 08, 2005 at 02:59:53PM -0700, Andrew Morton wrote:
> > On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
> ^^
> It's been over two weeks and nobody has complained about anything.
Two weeks isn't that long IMO (I only just noticed myself).
>
Chris Wedgwood <[EMAIL PROTECTED]> wrote:
>
> On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
^^
It's been over two weeks and nobody has complained about anything.
>
> > [PATCH] i386: Selectable Frequency of the Timer Interrupt
>
> [...]
>
> > +choice
On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
> [PATCH] i386: Selectable Frequency of the Timer Interrupt
[...]
> +choice
> + prompt "Timer frequency"
> + default HZ_250
WHAT?
The previous value here i386 is 1000 --- so why is the default 250.
Changing
On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
[PATCH] i386: Selectable Frequency of the Timer Interrupt
[...]
+choice
+ prompt Timer frequency
+ default HZ_250
WHAT?
The previous value here i386 is 1000 --- so why is the default 250.
Changing the
Chris Wedgwood [EMAIL PROTECTED] wrote:
On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
^^
It's been over two weeks and nobody has complained about anything.
[PATCH] i386: Selectable Frequency of the Timer Interrupt
[...]
+choice
+ prompt
On Fri, Jul 08, 2005 at 02:59:53PM -0700, Andrew Morton wrote:
On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
^^
It's been over two weeks and nobody has complained about anything.
Two weeks isn't that long IMO (I only just noticed myself).
Because
On Fri, 8 Jul 2005, Andrew Morton wrote:
The previous value here i386 is 1000 --- so why is the default 250.
Because 1000 is too high.
Yes. I chose 1000 originally partly as a way to make sure that people that
assumed HZ was 100 would get a swift kick in the pants. That meant making
a
On Fri, 2005-07-08 at 14:59 -0700, Andrew Morton wrote:
Chris Wedgwood [EMAIL PROTECTED] wrote:
On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
^^
It's been over two weeks and nobody has complained about anything.
Wrong, I complained loudly about
301 - 400 of 405 matches
Mail list logo
