> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> On Wed, 3 Oct 2007, Chuck Ebbert wrote:
>>
>> But we reduce the number of samples because some ticks just never
>> happen when the timers get rounded:
>>
>> No rounding:
>>
>> tick ... tick
>> 1 running
> "AM" == Andrew Morton <[EMAIL PROTECTED]> writes:
AM> On Tue, 02 Oct 2007 23:37:31 +0200 (CEST)
AM> Anders Bostr__m <[EMAIL PROTECTED]> wrote:
>> My computer suffers from high load average when the system is idle,
>> introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
>>
Linus Torvalds wrote:
On Wed, 3 Oct 2007, Arjan van de Ven wrote:
not sure this is going to help; I mean, the load gets only updated in actual
timer interrupts... and on a tickless system there's very few of those
around. and usually at places round_jiffies() already put a timer on.
On Wed, 3 Oct 2007, Arjan van de Ven wrote:
>
> not sure this is going to help; I mean, the load gets only updated in actual
> timer interrupts... and on a tickless system there's very few of those
> around. and usually at places round_jiffies() already put a timer on.
Yeah, you're right.
Linus Torvalds wrote:
Without this, I can easily imagine that the rounding code tends to try to
round to an even second, and the load-average code generally also runs at
even seconds!
Linus
---
include/linux/sched.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
On Wed, 3 Oct 2007, Chuck Ebbert wrote:
>
> But we reduce the number of samples because some ticks just never
> happen when the timers get rounded:
>
> No rounding:
>
> tick ... tick
> 1 running1 running
>
> Rounded:
>
> tick
> 2 running
>
> In
On 10/02/2007 07:26 PM, Arjan van de Ven wrote:
> On Tue, 02 Oct 2007 18:33:58 -0400
>> Or, everybody wakes up at once right when we are taking a sample. :)
>
> nice try but we sample every timer tick; this code being timer driven
> makes it what you say it is regardless of *which* timer tick it
On Tue, Oct 02, 2007 at 11:37:31PM +0200, Anders Bostr?m wrote:
> Hi!
>
> My computer suffers from high load average when the system is idle,
> introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
Another datapoint: I observe a similar effect on both of my alphas:
top - 09:30:43 up
> "AvdV" == Arjan van de Ven <[EMAIL PROTECTED]> writes:
AvdV> Anders Boström wrote:
>> Hi!
>>
>> My computer suffers from high load average when the system is idle,
>> introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
>>
>> Long story:
>>
>> 2.6.20 and all later
AvdV == Arjan van de Ven [EMAIL PROTECTED] writes:
AvdV Anders Boström wrote:
Hi!
My computer suffers from high load average when the system is idle,
introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
Long story:
2.6.20 and all later versions I've tested,
On Tue, Oct 02, 2007 at 11:37:31PM +0200, Anders Bostr?m wrote:
Hi!
My computer suffers from high load average when the system is idle,
introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
Another datapoint: I observe a similar effect on both of my alphas:
top - 09:30:43 up 13
On 10/02/2007 07:26 PM, Arjan van de Ven wrote:
On Tue, 02 Oct 2007 18:33:58 -0400
Or, everybody wakes up at once right when we are taking a sample. :)
nice try but we sample every timer tick; this code being timer driven
makes it what you say it is regardless of *which* timer tick it
On Wed, 3 Oct 2007, Chuck Ebbert wrote:
But we reduce the number of samples because some ticks just never
happen when the timers get rounded:
No rounding:
tick ... tick
1 running1 running
Rounded:
tick
2 running
In the first case
Linus Torvalds wrote:
Without this, I can easily imagine that the rounding code tends to try to
round to an even second, and the load-average code generally also runs at
even seconds!
Linus
---
include/linux/sched.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
On Wed, 3 Oct 2007, Arjan van de Ven wrote:
not sure this is going to help; I mean, the load gets only updated in actual
timer interrupts... and on a tickless system there's very few of those
around. and usually at places round_jiffies() already put a timer on.
Yeah, you're right.
Linus Torvalds wrote:
On Wed, 3 Oct 2007, Arjan van de Ven wrote:
not sure this is going to help; I mean, the load gets only updated in actual
timer interrupts... and on a tickless system there's very few of those
around. and usually at places round_jiffies() already put a timer on.
AM == Andrew Morton [EMAIL PROTECTED] writes:
AM On Tue, 02 Oct 2007 23:37:31 +0200 (CEST)
AM Anders Bostr__m [EMAIL PROTECTED] wrote:
My computer suffers from high load average when the system is idle,
introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
Long story:
LT == Linus Torvalds [EMAIL PROTECTED] writes:
LT On Wed, 3 Oct 2007, Chuck Ebbert wrote:
But we reduce the number of samples because some ticks just never
happen when the timers get rounded:
No rounding:
tick ... tick
1 running1 running
Rounded:
Arjan van de Ven wrote:
On Tue, 02 Oct 2007 18:46:18 -0400
On a related note, {set/get}itimer() currently are buggy (since
2.6.11 or so), also due to this round_jiffies() thing I believe.
I very much believe that it is totally unrelated... most of all since
round_jiffies() wasn't in the
On Tue, 02 Oct 2007 18:33:58 -0400
> Or, everybody wakes up at once right when we are taking a sample. :)
nice try but we sample every timer tick; this code being timer driven
makes it what you say it is regardless of *which* timer tick it
happens at ;)
-
To unsubscribe from this list: send the
On Tue, 02 Oct 2007 18:46:18 -0400
>
> On a related note, {set/get}itimer() currently are buggy (since
> 2.6.11 or so), also due to this round_jiffies() thing I believe.
I very much believe that it is totally unrelated... most of all since
round_jiffies() wasn't in the kernel then an also isn't
On Tue, 2 Oct 2007 15:32:53 -0700 (PDT)
> And I wonder if the same kind thing is effectively happening here:
> the code is written so that it *tries* to sleep, but the rounding of
> the clock basically means that it's trying to sleep using a different
> clock than the one we're using to wake
Anders Boström wrote:
Hi!
My computer suffers from high load average when the system is idle,
introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
Long story:
2.6.20 and all later versions I've tested, including 2.6.21 and
2.6.22, make the load average high. Even when the computer
Linus Torvalds wrote:
On Tue, 2 Oct 2007, Andrew Morton wrote:
This is unexpected. High load average is due to either a task chewing a
lot of CPU time or a task stuck in uninterruptible sleep.
Not necessarily.
We saw high loadaverages with the timer bogosity with "gettimeofday()" and
Linus Torvalds wrote:
I wonder if the whole "round_jiffies()" thing should be written so that it
never rounds down, or at least never rounds down to before the current
second!
that's what it is supposed to do already...
166
167 if (j <= jiffies) /* rounding ate our timeout
On 10/02/2007 06:07 PM, Andrew Morton wrote:
> On Tue, 02 Oct 2007 23:37:31 +0200 (CEST)
> Anders Bostr__m <[EMAIL PROTECTED]> wrote:
>
>> My computer suffers from high load average when the system is idle,
>> introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
>>
>> Long story:
>>
>>
On Tue, 2 Oct 2007, Andrew Morton wrote:
>
> This is unexpected. High load average is due to either a task chewing a
> lot of CPU time or a task stuck in uninterruptible sleep.
Not necessarily.
We saw high loadaverages with the timer bogosity with "gettimeofday()" and
"select()" not
On Tue, 02 Oct 2007 23:37:31 +0200 (CEST)
Anders Bostr__m <[EMAIL PROTECTED]> wrote:
> My computer suffers from high load average when the system is idle,
> introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
>
> Long story:
>
> 2.6.20 and all later versions I've tested, including
Hi!
My computer suffers from high load average when the system is idle,
introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
Long story:
2.6.20 and all later versions I've tested, including 2.6.21 and
2.6.22, make the load average high. Even when the computer is totally
idle (I've
Hi!
My computer suffers from high load average when the system is idle,
introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
Long story:
2.6.20 and all later versions I've tested, including 2.6.21 and
2.6.22, make the load average high. Even when the computer is totally
idle (I've
On Tue, 02 Oct 2007 23:37:31 +0200 (CEST)
Anders Bostr__m [EMAIL PROTECTED] wrote:
My computer suffers from high load average when the system is idle,
introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
Long story:
2.6.20 and all later versions I've tested, including 2.6.21
On Tue, 2 Oct 2007, Andrew Morton wrote:
This is unexpected. High load average is due to either a task chewing a
lot of CPU time or a task stuck in uninterruptible sleep.
Not necessarily.
We saw high loadaverages with the timer bogosity with gettimeofday() and
select() not agreeing, so
On 10/02/2007 06:07 PM, Andrew Morton wrote:
On Tue, 02 Oct 2007 23:37:31 +0200 (CEST)
Anders Bostr__m [EMAIL PROTECTED] wrote:
My computer suffers from high load average when the system is idle,
introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
Long story:
2.6.20 and all
Linus Torvalds wrote:
I wonder if the whole round_jiffies() thing should be written so that it
never rounds down, or at least never rounds down to before the current
second!
that's what it is supposed to do already...
166
167 if (j = jiffies) /* rounding ate our timeout entirely;
Linus Torvalds wrote:
On Tue, 2 Oct 2007, Andrew Morton wrote:
This is unexpected. High load average is due to either a task chewing a
lot of CPU time or a task stuck in uninterruptible sleep.
Not necessarily.
We saw high loadaverages with the timer bogosity with gettimeofday() and
Anders Boström wrote:
Hi!
My computer suffers from high load average when the system is idle,
introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
Long story:
2.6.20 and all later versions I've tested, including 2.6.21 and
2.6.22, make the load average high. Even when the computer
On Tue, 2 Oct 2007 15:32:53 -0700 (PDT)
And I wonder if the same kind thing is effectively happening here:
the code is written so that it *tries* to sleep, but the rounding of
the clock basically means that it's trying to sleep using a different
clock than the one we're using to wake things
On Tue, 02 Oct 2007 18:46:18 -0400
On a related note, {set/get}itimer() currently are buggy (since
2.6.11 or so), also due to this round_jiffies() thing I believe.
I very much believe that it is totally unrelated... most of all since
round_jiffies() wasn't in the kernel then an also isn't
On Tue, 02 Oct 2007 18:33:58 -0400
Or, everybody wakes up at once right when we are taking a sample. :)
nice try but we sample every timer tick; this code being timer driven
makes it what you say it is regardless of *which* timer tick it
happens at ;)
-
To unsubscribe from this list: send the
Arjan van de Ven wrote:
On Tue, 02 Oct 2007 18:46:18 -0400
On a related note, {set/get}itimer() currently are buggy (since
2.6.11 or so), also due to this round_jiffies() thing I believe.
I very much believe that it is totally unrelated... most of all since
round_jiffies() wasn't in the
40 matches
Mail list logo
