Hi,
On Wed, 18 Jul 2007, Ingo Molnar wrote:
> > Why do you constantly stress level 19? Yes, that one is special, all
> > other positive levels were already relatively consistent.
>
> i constantly stress it for the reason i mentioned a good number of
> times: because it's by far the most
Hi,
On Wed, 18 Jul 2007, Ingo Molnar wrote:
> > > [more rude insults deleted]
> > > I've been waiting for that obvious question, and i _might_ be able
> > > to answer it, but somehow it never occured to you ;-) Thanks,
>
> the ";-)" emoticon (and its contents) clearly signals this as a
>
Hi,
On Wed, 18 Jul 2007, Ingo Molnar wrote:
[more rude insults deleted]
I've been waiting for that obvious question, and i _might_ be able
to answer it, but somehow it never occured to you ;-) Thanks,
the ;-) emoticon (and its contents) clearly signals this as a
sarcastic,
Hi,
On Wed, 18 Jul 2007, Ingo Molnar wrote:
Why do you constantly stress level 19? Yes, that one is special, all
other positive levels were already relatively consistent.
i constantly stress it for the reason i mentioned a good number of
times: because it's by far the most commonly
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> Don't make such suggestions if you have no idea how insulting they
> are. Especially the one deleted insult above where you have the
> impertinence to quote it, such tone is more appropriate between lord
> and inferior, where the latter have to make
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> > _changing_ it is an option within reason, and we've done it a couple
> > of times already in the past, and even within CFS (as Peter
> > correctly observed) we've been through a couple of iterations
> > already. And as i mentioned it before, the
Hi,
On Wed, 18 Jul 2007, Ingo Molnar wrote:
> _changing_ it is an option within reason, and we've done it a couple of
> times already in the past, and even within CFS (as Peter correctly
> observed) we've been through a couple of iterations already. And as i
> mentioned it before, the outer
Hi,
On Wed, 18 Jul 2007, Peter Zijlstra wrote:
> The only expectation is that a process with a lower nice level gets more
> time. Any other expectation is a bug.
Yes, users are buggy, they expect a lot of stupid things...
Is this really reason enough to break this?
What exactly is the damage
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> > By breaking the UNIX model of nice levels. Not an option in my book.
>
> Breaking user expectations of nice levels is?
_changing_ it is an option within reason, and we've done it a couple of
times already in the past, and even within CFS (as Peter
On Wed, 2007-07-18 at 15:26 +0200, Roman Zippel wrote:
> Hi,
>
> On Wed, 18 Jul 2007, Peter Zijlstra wrote:
>
> > By breaking the UNIX model of nice levels. Not an option in my book.
>
> BTW what is the "UNIX model of nice levels"?
>
> SUS specifies the limit via NZERO, which is defined as
Hi,
On Wed, 18 Jul 2007, Peter Zijlstra wrote:
> By breaking the UNIX model of nice levels. Not an option in my book.
BTW what is the "UNIX model of nice levels"?
SUS specifies the limit via NZERO, which is defined as "Minimum Acceptable
Value: 20", I can't find any information that it must
On Wed, 2007-07-18 at 15:07 +0200, Roman Zippel wrote:
> Hi,
>
> On Wed, 18 Jul 2007, Peter Zijlstra wrote:
>
> > By breaking the UNIX model of nice levels. Not an option in my book.
>
> Breaking user expectations of nice levels is?
Hi,
On Wed, 18 Jul 2007, Peter Zijlstra wrote:
> By breaking the UNIX model of nice levels. Not an option in my book.
Breaking user expectations of nice levels is?
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
* Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-07-18 at 14:45 +0200, Roman Zippel wrote:
> > Hi,
> >
> > On Wed, 18 Jul 2007, Peter Zijlstra wrote:
> >
> > > I actually like the extra range, it allows for a much softer punch of
> > > background tasks even on somewhat slower boxen.
On Wed, 2007-07-18 at 14:45 +0200, Roman Zippel wrote:
> Hi,
>
> On Wed, 18 Jul 2007, Peter Zijlstra wrote:
>
> > I actually like the extra range, it allows for a much softer punch of
> > background tasks even on somewhat slower boxen.
>
> The extra range is not really a problem, in
>
>
Hi,
On Wed, 18 Jul 2007, Peter Zijlstra wrote:
> I actually like the extra range, it allows for a much softer punch of
> background tasks even on somewhat slower boxen.
The extra range is not really a problem, in
http://www.ussg.iu.edu/hypermail/linux/kernel/0707.2/0850.html
I suggested how
Hi,
On Wed, 18 Jul 2007, Ingo Molnar wrote:
> > > Roman, please do me a favor, and ask me the following question:
> > >
> > > [insult deleted]
> In this discussion about
> nice levels you were (very) agressively asserting things that were
> untrue,
Instead of simply asserting things, how
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> On Tue, 17 Jul 2007, Ingo Molnar wrote:
>
> > Roman, please do me a favor, and ask me the following question:
> >
> > " Ingo, you've been maintaining the scheduler for years. In fact you
> >wrote the old nice code we are talking about here. You
On Mon, 2007-07-16 at 10:47 -0700, Linus Torvalds wrote:
>
> On Mon, 16 Jul 2007, Roman Zippel wrote:
> >
> > To illustrate the problem a little different: a task with a nice level -20
> > got around 700% more cpu time (or 8 times more), now it gets 8500% more
> > cpu time (or 86.7 times more).
On Mon, 2007-07-16 at 10:47 -0700, Linus Torvalds wrote:
On Mon, 16 Jul 2007, Roman Zippel wrote:
To illustrate the problem a little different: a task with a nice level -20
got around 700% more cpu time (or 8 times more), now it gets 8500% more
cpu time (or 86.7 times more).
Ingo,
* Roman Zippel [EMAIL PROTECTED] wrote:
On Tue, 17 Jul 2007, Ingo Molnar wrote:
Roman, please do me a favor, and ask me the following question:
Ingo, you've been maintaining the scheduler for years. In fact you
wrote the old nice code we are talking about here. You changed it a
Hi,
On Wed, 18 Jul 2007, Ingo Molnar wrote:
Roman, please do me a favor, and ask me the following question:
[insult deleted]
In this discussion about
nice levels you were (very) agressively asserting things that were
untrue,
Instead of simply asserting things, how about you
Hi,
On Wed, 18 Jul 2007, Peter Zijlstra wrote:
I actually like the extra range, it allows for a much softer punch of
background tasks even on somewhat slower boxen.
The extra range is not really a problem, in
http://www.ussg.iu.edu/hypermail/linux/kernel/0707.2/0850.html
I suggested how we
On Wed, 2007-07-18 at 14:45 +0200, Roman Zippel wrote:
Hi,
On Wed, 18 Jul 2007, Peter Zijlstra wrote:
I actually like the extra range, it allows for a much softer punch of
background tasks even on somewhat slower boxen.
The extra range is not really a problem, in
* Peter Zijlstra [EMAIL PROTECTED] wrote:
On Wed, 2007-07-18 at 14:45 +0200, Roman Zippel wrote:
Hi,
On Wed, 18 Jul 2007, Peter Zijlstra wrote:
I actually like the extra range, it allows for a much softer punch of
background tasks even on somewhat slower boxen.
The extra
Hi,
On Wed, 18 Jul 2007, Peter Zijlstra wrote:
By breaking the UNIX model of nice levels. Not an option in my book.
Breaking user expectations of nice levels is?
bye, Roman
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
On Wed, 2007-07-18 at 15:07 +0200, Roman Zippel wrote:
Hi,
On Wed, 18 Jul 2007, Peter Zijlstra wrote:
By breaking the UNIX model of nice levels. Not an option in my book.
Breaking user expectations of nice levels is?
Hi,
On Wed, 18 Jul 2007, Peter Zijlstra wrote:
By breaking the UNIX model of nice levels. Not an option in my book.
BTW what is the UNIX model of nice levels?
SUS specifies the limit via NZERO, which is defined as Minimum Acceptable
Value: 20, I can't find any information that it must be 20.
On Wed, 2007-07-18 at 15:26 +0200, Roman Zippel wrote:
Hi,
On Wed, 18 Jul 2007, Peter Zijlstra wrote:
By breaking the UNIX model of nice levels. Not an option in my book.
BTW what is the UNIX model of nice levels?
SUS specifies the limit via NZERO, which is defined as Minimum
* Roman Zippel [EMAIL PROTECTED] wrote:
By breaking the UNIX model of nice levels. Not an option in my book.
Breaking user expectations of nice levels is?
_changing_ it is an option within reason, and we've done it a couple of
times already in the past, and even within CFS (as Peter
Hi,
On Wed, 18 Jul 2007, Peter Zijlstra wrote:
The only expectation is that a process with a lower nice level gets more
time. Any other expectation is a bug.
Yes, users are buggy, they expect a lot of stupid things...
Is this really reason enough to break this?
What exactly is the damage if
Hi,
On Wed, 18 Jul 2007, Ingo Molnar wrote:
_changing_ it is an option within reason, and we've done it a couple of
times already in the past, and even within CFS (as Peter correctly
observed) we've been through a couple of iterations already. And as i
mentioned it before, the outer edge
* Roman Zippel [EMAIL PROTECTED] wrote:
_changing_ it is an option within reason, and we've done it a couple
of times already in the past, and even within CFS (as Peter
correctly observed) we've been through a couple of iterations
already. And as i mentioned it before, the outer edge
* Roman Zippel [EMAIL PROTECTED] wrote:
Don't make such suggestions if you have no idea how insulting they
are. Especially the one deleted insult above where you have the
impertinence to quote it, such tone is more appropriate between lord
and inferior, where the latter have to make a
Hi,
On Tue, 17 Jul 2007, Ingo Molnar wrote:
> * Roman Zippel <[EMAIL PROTECTED]> wrote:
>
> > > > It's nice that these artifacts are gone, but that still doesn't
> > > > explain why this ratio had to be increase that much from around
> > > > 1:10 to 1:69.
> > >
> > > More dynamic range is
Hi,
On Tue, 17 Jul 2007, Ingo Molnar wrote:
> Roman, please do me a favor, and ask me the following question:
>
> " Ingo, you've been maintaining the scheduler for years. In fact you
>wrote the old nice code we are talking about here. You changed it a
>number of times since then. So
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> Nice level 19 shows the largest artifacts, as that level only gets a
> single tick, so the ratio is often 1:HZ/10 (except for 1000HZ where
> it's 5:100). [...]
Roman, please do me a favor, and ask me the following question:
" Ingo, you've been
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> > > It's nice that these artifacts are gone, but that still doesn't
> > > explain why this ratio had to be increase that much from around
> > > 1:10 to 1:69.
> >
> > More dynamic range is better? If you actually want a task to get 20x
> > the CPU
* Roman Zippel [EMAIL PROTECTED] wrote:
It's nice that these artifacts are gone, but that still doesn't
explain why this ratio had to be increase that much from around
1:10 to 1:69.
More dynamic range is better? If you actually want a task to get 20x
the CPU time of another,
* Roman Zippel [EMAIL PROTECTED] wrote:
Nice level 19 shows the largest artifacts, as that level only gets a
single tick, so the ratio is often 1:HZ/10 (except for 1000HZ where
it's 5:100). [...]
Roman, please do me a favor, and ask me the following question:
Ingo, you've been
Hi,
On Tue, 17 Jul 2007, Ingo Molnar wrote:
Roman, please do me a favor, and ask me the following question:
Ingo, you've been maintaining the scheduler for years. In fact you
wrote the old nice code we are talking about here. You changed it a
number of times since then. So you
Hi,
On Tue, 17 Jul 2007, Ingo Molnar wrote:
* Roman Zippel [EMAIL PROTECTED] wrote:
It's nice that these artifacts are gone, but that still doesn't
explain why this ratio had to be increase that much from around
1:10 to 1:69.
More dynamic range is better? If you actually
Hi,
On Tue, 17 Jul 2007, I wrote:
> Playing around with some other nice levels, confirms the theory that
> something is a little off, so I'm quite correct at saying that the ratio
> _should_ be 1:10.
Rechecking everything there was actually a small error in my test program,
so the ratio
Hi,
On Tue, 17 Jul 2007, Ingo Molnar wrote:
> * Roman Zippel <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > On Mon, 16 Jul 2007, Ingo Molnar wrote:
> >
> > > and note that even on the old scheduler, nice-0 was "3200% more
> > > powerful" than nice +19 (with CONFIG_HZ=300),
> >
> > How did you
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Mon, 16 Jul 2007, Ingo Molnar wrote:
>
> > and note that even on the old scheduler, nice-0 was "3200% more
> > powerful" than nice +19 (with CONFIG_HZ=300),
>
> How did you get that value? At any HZ the ratio should be around 1:10
> (+-
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> and note that even on the old scheduler, nice-0 was "3200% more
> powerful" than nice +19 (with CONFIG_HZ=300),
How did you get that value? At any HZ the ratio should be around 1:10
(+- rounding error).
> in fact i like it that nice -20 has a
Hi,
On Mon, 16 Jul 2007, Matt Mackall wrote:
> > It's nice that these artifacts are gone, but that still doesn't explain
> > why this ratio had to be increase that much from around 1:10 to 1:69.
>
> More dynamic range is better? If you actually want a task to get 20x
> the CPU time of another,
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> More dynamic range is better? If you actually want a task to get 20x
> the CPU time of another, the older scheduler doesn't really allow it.
>
> Getting 1/69th of a modern CPU is still a fair number of cycles.
> Nevermind 1/69th of a machine with >
On Mon, Jul 16, 2007 at 04:01:17PM +0200, Roman Zippel wrote:
> Hi,
>
> On Mon, 16 Jul 2007, Ingo Molnar wrote:
>
> > to sum it up: a nice +19 task (the most commonly used nice level in
> > practice) gets 9.1%, 3.9%, 3.1% of CPU time on the old scheduler,
> > depending on the value of HZ. This
Hi,
On Mon, 16 Jul 2007, Linus Torvalds wrote:
> How about trying a much less aggressive nice-level (and preferably linear,
> not exponential)?
I think the exponential increase isn't the problem. The old code did
approximate something like this rather crudely with the result that there
was a
On Mon, 16 Jul 2007, Roman Zippel wrote:
>
> To illustrate the problem a little different: a task with a nice level -20
> got around 700% more cpu time (or 8 times more), now it gets 8500% more
> cpu time (or 86.7 times more).
Ingo, that _does_ sound excessive.
How about trying a much less
Ingo Molnar wrote:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
* James Bruce <[EMAIL PROTECTED]> wrote:
While we're at it, isn't the comment above the wmult table incorrect?
The multiplier is 1.25, meaning a 25% change per nice level, not 10%.
yes, the weight multiplier 1.25, but the actual
Roman Zippel wrote:
> On Mon, 16 Jul 2007, Ingo Molnar wrote:
> > to sum it up: a nice +19 task (the most commonly used nice level in
> > practice) gets 9.1%, 3.9%, 3.1% of CPU time on the old scheduler,
> > depending on the value of HZ. This is quite inconsistent and illogical.
>
> You're correct
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> to sum it up: a nice +19 task (the most commonly used nice level in
> practice) gets 9.1%, 3.9%, 3.1% of CPU time on the old scheduler,
> depending on the value of HZ. This is quite inconsistent and illogical.
You're correct that you can find
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> > It has been a common request for nice levels to be more logical
> > (i.e. to make them universal and to detach them from HZ) and for
> > them to be more effective as well.
>
> Huh? What has this to do with HZ? The scheduler used ticks internally,
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> > > > As soon as you add another loop the difference changes again,
> > > > while it's always correct to say it gets 25% more cpu time [...]
> > >
> > > yep, and i'll add the relative effect to the comment too.
> >
> > Why did you cut off the rest
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Jul 2007, Ingo Molnar wrote:
>
> > > As soon as you add another loop the difference changes again,
> > > while it's always correct to say it gets 25% more cpu time [...]
> >
> > yep, and i'll add the relative effect to the comment too.
>
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> > As soon as you add another loop the difference changes again, while
> > it's always correct to say it gets 25% more cpu time [...]
>
> yep, and i'll add the relative effect to the comment too.
Why did you cut off the rest of the sentence?
To
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> > yes, the weight multiplier 1.25, but the actual difference in CPU
> > utilization, when running two CPU intense tasks, is ~10%:
> >
> > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> > 8246 mingo 20 0 1576 244 196
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> yes, the weight multiplier 1.25, but the actual difference in CPU
> utilization, when running two CPU intense tasks, is ~10%:
>
> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 8246 mingo 20 0 1576 244 196 R 55
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * James Bruce <[EMAIL PROTECTED]> wrote:
>
> > While we're at it, isn't the comment above the wmult table incorrect?
> > The multiplier is 1.25, meaning a 25% change per nice level, not 10%.
>
> yes, the weight multiplier 1.25, but the actual
* James Bruce <[EMAIL PROTECTED]> wrote:
> While we're at it, isn't the comment above the wmult table incorrect?
> The multiplier is 1.25, meaning a 25% change per nice level, not 10%.
yes, the weight multiplier 1.25, but the actual difference in CPU
utilization, when running two CPU intense
Thomas Gleixner wrote:
Roman Zippel noticed inconsistency of the wmult table.
wmult[16] has a missing digit.
[snip]
While we're at it, isn't the comment above the wmult table incorrect?
The multiplier is 1.25, meaning a 25% change per nice level, not 10%.
- Jim
-
To unsubscribe from this
Thomas Gleixner wrote:
Roman Zippel noticed inconsistency of the wmult table.
wmult[16] has a missing digit.
[snip]
While we're at it, isn't the comment above the wmult table incorrect?
The multiplier is 1.25, meaning a 25% change per nice level, not 10%.
- Jim
-
To unsubscribe from this
* James Bruce [EMAIL PROTECTED] wrote:
While we're at it, isn't the comment above the wmult table incorrect?
The multiplier is 1.25, meaning a 25% change per nice level, not 10%.
yes, the weight multiplier 1.25, but the actual difference in CPU
utilization, when running two CPU intense
* Ingo Molnar [EMAIL PROTECTED] wrote:
* James Bruce [EMAIL PROTECTED] wrote:
While we're at it, isn't the comment above the wmult table incorrect?
The multiplier is 1.25, meaning a 25% change per nice level, not 10%.
yes, the weight multiplier 1.25, but the actual difference in CPU
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
yes, the weight multiplier 1.25, but the actual difference in CPU
utilization, when running two CPU intense tasks, is ~10%:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
8246 mingo 20 0 1576 244 196 R 55 0.0
* Roman Zippel [EMAIL PROTECTED] wrote:
yes, the weight multiplier 1.25, but the actual difference in CPU
utilization, when running two CPU intense tasks, is ~10%:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
8246 mingo 20 0 1576 244 196 R 55 0.0
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
As soon as you add another loop the difference changes again, while
it's always correct to say it gets 25% more cpu time [...]
yep, and i'll add the relative effect to the comment too.
Why did you cut off the rest of the sentence?
To
* Roman Zippel [EMAIL PROTECTED] wrote:
On Mon, 16 Jul 2007, Ingo Molnar wrote:
As soon as you add another loop the difference changes again,
while it's always correct to say it gets 25% more cpu time [...]
yep, and i'll add the relative effect to the comment too.
Why did you
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
As soon as you add another loop the difference changes again,
while it's always correct to say it gets 25% more cpu time [...]
yep, and i'll add the relative effect to the comment too.
Why did you cut off the rest of the sentence?
* Roman Zippel [EMAIL PROTECTED] wrote:
It has been a common request for nice levels to be more logical
(i.e. to make them universal and to detach them from HZ) and for
them to be more effective as well.
Huh? What has this to do with HZ? The scheduler used ticks internally,
but it's
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
to sum it up: a nice +19 task (the most commonly used nice level in
practice) gets 9.1%, 3.9%, 3.1% of CPU time on the old scheduler,
depending on the value of HZ. This is quite inconsistent and illogical.
You're correct that you can find
Roman Zippel wrote:
On Mon, 16 Jul 2007, Ingo Molnar wrote:
to sum it up: a nice +19 task (the most commonly used nice level in
practice) gets 9.1%, 3.9%, 3.1% of CPU time on the old scheduler,
depending on the value of HZ. This is quite inconsistent and illogical.
You're correct that you
Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
* James Bruce [EMAIL PROTECTED] wrote:
While we're at it, isn't the comment above the wmult table incorrect?
The multiplier is 1.25, meaning a 25% change per nice level, not 10%.
yes, the weight multiplier 1.25, but the actual
On Mon, 16 Jul 2007, Roman Zippel wrote:
To illustrate the problem a little different: a task with a nice level -20
got around 700% more cpu time (or 8 times more), now it gets 8500% more
cpu time (or 86.7 times more).
Ingo, that _does_ sound excessive.
How about trying a much less
Hi,
On Mon, 16 Jul 2007, Linus Torvalds wrote:
How about trying a much less aggressive nice-level (and preferably linear,
not exponential)?
I think the exponential increase isn't the problem. The old code did
approximate something like this rather crudely with the result that there
was a
On Mon, Jul 16, 2007 at 04:01:17PM +0200, Roman Zippel wrote:
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
to sum it up: a nice +19 task (the most commonly used nice level in
practice) gets 9.1%, 3.9%, 3.1% of CPU time on the old scheduler,
depending on the value of HZ. This is quite
* Matt Mackall [EMAIL PROTECTED] wrote:
More dynamic range is better? If you actually want a task to get 20x
the CPU time of another, the older scheduler doesn't really allow it.
Getting 1/69th of a modern CPU is still a fair number of cycles.
Nevermind 1/69th of a machine with 64
Hi,
On Mon, 16 Jul 2007, Matt Mackall wrote:
It's nice that these artifacts are gone, but that still doesn't explain
why this ratio had to be increase that much from around 1:10 to 1:69.
More dynamic range is better? If you actually want a task to get 20x
the CPU time of another, the
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
and note that even on the old scheduler, nice-0 was 3200% more
powerful than nice +19 (with CONFIG_HZ=300),
How did you get that value? At any HZ the ratio should be around 1:10
(+- rounding error).
in fact i like it that nice -20 has a slightly
* Roman Zippel [EMAIL PROTECTED] wrote:
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
and note that even on the old scheduler, nice-0 was 3200% more
powerful than nice +19 (with CONFIG_HZ=300),
How did you get that value? At any HZ the ratio should be around 1:10
(+- rounding
Hi,
On Tue, 17 Jul 2007, Ingo Molnar wrote:
* Roman Zippel [EMAIL PROTECTED] wrote:
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
and note that even on the old scheduler, nice-0 was 3200% more
powerful than nice +19 (with CONFIG_HZ=300),
How did you get that value? At any
Hi,
On Tue, 17 Jul 2007, I wrote:
Playing around with some other nice levels, confirms the theory that
something is a little off, so I'm quite correct at saying that the ratio
_should_ be 1:10.
Rechecking everything there was actually a small error in my test program,
so the ratio should
Roman Zippel noticed inconsistency of the wmult table.
wmult[16] has a missing digit.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
diff --git a/kernel/sched.c b/kernel/sched.c
index 0559665..3332bbb 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -750,7 +750,7 @@ static const u32
Roman Zippel noticed inconsistency of the wmult table.
wmult[16] has a missing digit.
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
diff --git a/kernel/sched.c b/kernel/sched.c
index 0559665..3332bbb 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -750,7 +750,7 @@ static const u32
86 matches
Mail list logo
