[PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

What follows this email is a patch series for the latest version of the RSDL 
cpu scheduler (ie v0.29). I have addressed all bugs that I am able to 
reproduce in this version so if some people would be kind enough to test if 
there are any hidden bugs or oops lurking, it would be nice to know in 
anticipation of putting this back in -mm. Thanks.

Full patch for 2.6.21-rc3-mm2:
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.29.patch

Patch series (which will follow this email):
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2/

Changelog:
- Fixed the longstanding buggy bitmap problem which occurred due to swapping 
arrays when there were still tasks on the active array.
- Fixed preemption of realtime tasks when rt prio inheritance elevated their 
priority.
- Made kernel threads not be reniced to -5 by default
- Changed sched_yield behaviour of SCHED_NORMAL (SCHED_OTHER) to resemble 
realtime task yielding.

-- 
-ck

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

Hi Con,

On Sun, 2007-03-11 at 14:57 +1100, Con Kolivas wrote:
> What follows this email is a patch series for the latest version of the RSDL 
> cpu scheduler (ie v0.29). I have addressed all bugs that I am able to 
> reproduce in this version so if some people would be kind enough to test if 
> there are any hidden bugs or oops lurking, it would be nice to know in 
> anticipation of putting this back in -mm. Thanks.
> 
> Full patch for 2.6.21-rc3-mm2:
> http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.29.patch

I'm seeing a cpu distribution problem running this on my P4 box.

Scenario:
listening to music collection (mp3) via Amarok.  Enable Amarok
visualization gforce, and size such that X and gforce each use ~50% cpu.
Start rip/encode of new CD with grip/lame encoder.  Lame is set to use
both cpus, at nice 5.  Once the encoders start, they receive
considerable more cpu than nice 0 X/Gforce, taking ~120% and leaving the
remaining 80% for X/Gforce and Amarok (when it updates it's ~12k entry
database) to squabble over.

With 2.6.21-rc3,  X/Gforce maintain their ~50% cpu (remain smooth), and
the encoders (100%cpu bound) get whats left when Amarok isn't eating it.

I plunked the above patch into plain 2.6.21-rc3 and retested to
eliminate other mm tree differences, and it's repeatable.  The nice 5
cpu hogs always receive considerably more that the nice 0 sleepers.

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On Sunday 11 March 2007 22:39, Mike Galbraith wrote:
> Hi Con,
>
> On Sun, 2007-03-11 at 14:57 +1100, Con Kolivas wrote:
> > What follows this email is a patch series for the latest version of the
> > RSDL cpu scheduler (ie v0.29). I have addressed all bugs that I am able
> > to reproduce in this version so if some people would be kind enough to
> > test if there are any hidden bugs or oops lurking, it would be nice to
> > know in anticipation of putting this back in -mm. Thanks.
> >
> > Full patch for 2.6.21-rc3-mm2:
> > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.29
> >.patch
>
> I'm seeing a cpu distribution problem running this on my P4 box.
>
> Scenario:
> listening to music collection (mp3) via Amarok.  Enable Amarok
> visualization gforce, and size such that X and gforce each use ~50% cpu.
> Start rip/encode of new CD with grip/lame encoder.  Lame is set to use
> both cpus, at nice 5.  Once the encoders start, they receive
> considerable more cpu than nice 0 X/Gforce, taking ~120% and leaving the
> remaining 80% for X/Gforce and Amarok (when it updates it's ~12k entry
> database) to squabble over.
>
> With 2.6.21-rc3,  X/Gforce maintain their ~50% cpu (remain smooth), and
> the encoders (100%cpu bound) get whats left when Amarok isn't eating it.
>
> I plunked the above patch into plain 2.6.21-rc3 and retested to
> eliminate other mm tree differences, and it's repeatable.  The nice 5
> cpu hogs always receive considerably more that the nice 0 sleepers.

Thanks for the report. I'm assuming you're describing a single hyperthread P4 
here in SMP mode so 2 logical cores. Can you elaborate on whether there is 
any difference as to which cpu things are bound to as well? Can you also see 
what happens with lame not niced to +5 (ie at 0) and with lame at nice +19.

Thanks.

-- 
-ck

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Sun, 2007-03-11 at 22:48 +1100, Con Kolivas wrote:
> 
> Thanks for the report. I'm assuming you're describing a single hyperthread P4 
> here in SMP mode so 2 logical cores. Can you elaborate on whether there is 
> any difference as to which cpu things are bound to as well? Can you also see 
> what happens with lame not niced to +5 (ie at 0) and with lame at nice +19.

Yes, one P4/HT/SMP. No change at nice 0, but setting the encoders to
nice 19 did put X/gforce ~back where they were with 2.6.21-rc3.  Tasks
don't seem to be bound to any particular cpu, relies on load balancing
(which appears to be working).

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Ingo Molnar]

* Mike Galbraith <efault@gmx.de> wrote:

> > Full patch for 2.6.21-rc3-mm2: 
> > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.29.patch
> 
> I'm seeing a cpu distribution problem running this on my P4 box.

> With 2.6.21-rc3, X/Gforce maintain their ~50% cpu (remain smooth), and 
> the encoders (100%cpu bound) get whats left when Amarok isn't eating 
> it.
> 
> I plunked the above patch into plain 2.6.21-rc3 and retested to 
> eliminate other mm tree differences, and it's repeatable.  The nice 5 
> cpu hogs always receive considerably more that the nice 0 sleepers.

hm. Do you get the same same problem on UP too? (i.e. lets eliminate any 
SMP/HT artifacts)

	Ingo

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Sun, 2007-03-11 at 13:10 +0100, Ingo Molnar wrote:
> * Mike Galbraith <efault@gmx.de> wrote:
> 
> > > Full patch for 2.6.21-rc3-mm2: 
> > > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.29.patch
> > 
> > I'm seeing a cpu distribution problem running this on my P4 box.
> 
> > With 2.6.21-rc3, X/Gforce maintain their ~50% cpu (remain smooth), and 
> > the encoders (100%cpu bound) get whats left when Amarok isn't eating 
> > it.
> > 
> > I plunked the above patch into plain 2.6.21-rc3 and retested to 
> > eliminate other mm tree differences, and it's repeatable.  The nice 5 
> > cpu hogs always receive considerably more that the nice 0 sleepers.
> 
> hm. Do you get the same same problem on UP too? (i.e. lets eliminate any 
> SMP/HT artifacts)

I'll boot up nosmp and report back (but now it's time to take Opa to the
Gasthaus for his Sunday afternoon brewskies;)

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Sun, 2007-03-11 at 13:20 +0100, Mike Galbraith wrote:

> I'll boot up nosmp and report back

Hohum.  nosmp doesn't boot (locks after ide [bla] IRQ 14), will
recompile UP in the A.M. and try again.

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Sun, 2007-03-11 at 13:10 +0100, Ingo Molnar wrote:
> * Mike Galbraith <efault@gmx.de> wrote:
> 
> > > Full patch for 2.6.21-rc3-mm2: 
> > > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.29.patch
> > 
> > I'm seeing a cpu distribution problem running this on my P4 box.
> 
> > With 2.6.21-rc3, X/Gforce maintain their ~50% cpu (remain smooth), and 
> > the encoders (100%cpu bound) get whats left when Amarok isn't eating 
> > it.
> > 
> > I plunked the above patch into plain 2.6.21-rc3 and retested to 
> > eliminate other mm tree differences, and it's repeatable.  The nice 5 
> > cpu hogs always receive considerably more that the nice 0 sleepers.
> 
> hm. Do you get the same same problem on UP too? (i.e. lets eliminate any 
> SMP/HT artifacts)

Behavior is slightly different with a UP kernel.  Neither encoder
receives more cpu than X, but they each still receive more than gforce.
The distribution of X/Gforce vs lame/lame averages per eyeball to
roughly ~50:50.

I noticed Con posted an accounting fix, and applied it.  No change.

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On Monday 12 March 2007 18:22, Mike Galbraith wrote:
> On Sun, 2007-03-11 at 13:10 +0100, Ingo Molnar wrote:
> > * Mike Galbraith <efault@gmx.de> wrote:
> > > > Full patch for 2.6.21-rc3-mm2:
> > > > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-
> > > >0.29.patch
> > >
> > > I'm seeing a cpu distribution problem running this on my P4 box.
> > >
> > > With 2.6.21-rc3, X/Gforce maintain their ~50% cpu (remain smooth), and
> > > the encoders (100%cpu bound) get whats left when Amarok isn't eating
> > > it.
> > >
> > > I plunked the above patch into plain 2.6.21-rc3 and retested to
> > > eliminate other mm tree differences, and it's repeatable.  The nice 5
> > > cpu hogs always receive considerably more that the nice 0 sleepers.
> >
> > hm. Do you get the same same problem on UP too? (i.e. lets eliminate any
> > SMP/HT artifacts)
>
> Behavior is slightly different with a UP kernel.  Neither encoder
> receives more cpu than X, but they each still receive more than gforce.
> The distribution of X/Gforce vs lame/lame averages per eyeball to
> roughly ~50:50.
>
> I noticed Con posted an accounting fix, and applied it.  No change.

So the lames are nice 5 which means they should receive 75% of the cpu that 
nice 0 tasks receive so they should get 43% of the cpu...

Just a couple of questions;

The X/Gforce case; do they alternate cpu between them? By that I mean when 
they're the only thing running does the cpu load summate to 1 or does it 
summate to 2?

Gforce presumably is a 3d visualisation? Do you use one of the graphics card 
drivers listed that uses yield?

,----[grep -r sched_yield mesa]
| mesa/mesa/src/mesa/drivers/dri/r300/radeon_ioctl.c:       sched_yield();
| mesa/mesa/src/mesa/drivers/dri/i915tex/intel_batchpool.c:      
sched_yield();
| mesa/mesa/src/mesa/drivers/dri/i915tex/intel_batchbuffer.c:         
sched_yield();
| mesa/mesa/src/mesa/drivers/dri/common/vblank.h:#include <sched.h>   /* for 
sched_yield() */
| mesa/mesa/src/mesa/drivers/dri/common/vblank.h:#include <sched.h>   /* for 
sched_yield() */
| mesa/mesa/src/mesa/drivers/dri/common/vblank.h:      sched_yield();                                                   
\
| mesa/mesa/src/mesa/drivers/dri/unichrome/via_ioctl.c:      sched_yield();
| mesa/mesa/src/mesa/drivers/dri/i915/intel_ioctl.c:     sched_yield();
| mesa/mesa/src/mesa/drivers/dri/r200/r200_ioctl.c:       sched_yield();
`----

Thanks

-- 
-ck

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On Monday 12 March 2007 18:48, Con Kolivas wrote:
> On Monday 12 March 2007 18:22, Mike Galbraith wrote:
> > On Sun, 2007-03-11 at 13:10 +0100, Ingo Molnar wrote:
> > > * Mike Galbraith <efault@gmx.de> wrote:
> > > > > Full patch for 2.6.21-rc3-mm2:
> > > > > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsd
> > > > >l- 0.29.patch
> > > >
> > > > I'm seeing a cpu distribution problem running this on my P4 box.
> > > >
> > > > With 2.6.21-rc3, X/Gforce maintain their ~50% cpu (remain smooth),
> > > > and the encoders (100%cpu bound) get whats left when Amarok isn't
> > > > eating it.
> > > >
> > > > I plunked the above patch into plain 2.6.21-rc3 and retested to
> > > > eliminate other mm tree differences, and it's repeatable.  The nice 5
> > > > cpu hogs always receive considerably more that the nice 0 sleepers.
> > >
> > > hm. Do you get the same same problem on UP too? (i.e. lets eliminate
> > > any SMP/HT artifacts)
> >
> > Behavior is slightly different with a UP kernel.  Neither encoder
> > receives more cpu than X, but they each still receive more than gforce.
> > The distribution of X/Gforce vs lame/lame averages per eyeball to
> > roughly ~50:50.
> >
> > I noticed Con posted an accounting fix, and applied it.  No change.
>
> So the lames are nice 5 which means they should receive 75% of the cpu that
> nice 0 tasks receive so they should get 43% of the cpu...
>
> Just a couple of questions;
>
> The X/Gforce case; do they alternate cpu between them? By that I mean when
> they're the only thing running does the cpu load summate to 1 or does it
> summate to 2?

I'll save you the trouble. I just checked myself and indeed the load is only 
1. What this means is that although there are 2 tasks running, only one is 
running at any time making a total load of 1. So, if we add two other tasks 
that add 2 more to the load the total load is 3. However if we weight the 
other two tasks at nice 5, they only add .75 each to the load making a 
weighted total of 2.5. This means that X+Gforce together should get a total 
of 1/2.5 or 40% of the overall cpu. That sounds like exactly what you're 
describing is happening.

-- 
-ck

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:

> I'll save you the trouble. I just checked myself and indeed the load is only 
> 1. What this means is that although there are 2 tasks running, only one is 
> running at any time making a total load of 1. So, if we add two other tasks 
> that add 2 more to the load the total load is 3. However if we weight the 
> other two tasks at nice 5, they only add .75 each to the load making a 
> weighted total of 2.5. This means that X+Gforce together should get a total 
> of 1/2.5 or 40% of the overall cpu. That sounds like exactly what you're 
> describing is happening.

Hmm.  So... anything that's client/server is going to suffer horribly
unless niced tasks are niced all the way down to 19?

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:
> > I'll save you the trouble. I just checked myself and indeed the load is
> > only 1. What this means is that although there are 2 tasks running, only
> > one is running at any time making a total load of 1. So, if we add two
> > other tasks that add 2 more to the load the total load is 3. However if
> > we weight the other two tasks at nice 5, they only add .75 each to the
> > load making a weighted total of 2.5. This means that X+Gforce together
> > should get a total of 1/2.5 or 40% of the overall cpu. That sounds like
> > exactly what you're describing is happening.
>
> Hmm.  So... anything that's client/server is going to suffer horribly
> unless niced tasks are niced all the way down to 19?

Fortunately most client server models dont usually have mutually exclusive cpu 
use like this X case. There are many things about X that are still a little 
(/me tries to think of a relatively neutral term)... wanting. :(

-- 
-ck

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:
> > > I'll save you the trouble. I just checked myself and indeed the load is
> > > only 1. What this means is that although there are 2 tasks running, only
> > > one is running at any time making a total load of 1. So, if we add two
> > > other tasks that add 2 more to the load the total load is 3. However if
> > > we weight the other two tasks at nice 5, they only add .75 each to the
> > > load making a weighted total of 2.5. This means that X+Gforce together
> > > should get a total of 1/2.5 or 40% of the overall cpu. That sounds like
> > > exactly what you're describing is happening.
> >
> > Hmm.  So... anything that's client/server is going to suffer horribly
> > unless niced tasks are niced all the way down to 19?
> 
> Fortunately most client server models dont usually have mutually exclusive cpu 
> use like this X case. There are many things about X that are still a little 
> (/me tries to think of a relatively neutral term)... wanting. :(

But the reality of X is what we have to deal with.

This scheduler seems to close the corner cases of the interactivity
estimator, but this "any background load is palpable" thing is decidedly
detrimental to interactive feel.

When I looked into keeping interactive tasks responsive, I came to the
conclusion that I just couldn't get there from here across the full
spectrum of cpu usage without a scheduler hint.  Interactive feel is
absolutely dependent upon unfairness in many cases, and targeting that
unfairness gets it right where heuristics sometimes can't.

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On Monday 12 March 2007 20:38, Mike Galbraith wrote:
> On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> > On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > > On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:
> > > > I'll save you the trouble. I just checked myself and indeed the load
> > > > is only 1. What this means is that although there are 2 tasks
> > > > running, only one is running at any time making a total load of 1.
> > > > So, if we add two other tasks that add 2 more to the load the total
> > > > load is 3. However if we weight the other two tasks at nice 5, they
> > > > only add .75 each to the load making a weighted total of 2.5. This
> > > > means that X+Gforce together should get a total of 1/2.5 or 40% of
> > > > the overall cpu. That sounds like exactly what you're describing is
> > > > happening.
> > >
> > > Hmm.  So... anything that's client/server is going to suffer horribly
> > > unless niced tasks are niced all the way down to 19?
> >
> > Fortunately most client server models dont usually have mutually
> > exclusive cpu use like this X case. There are many things about X that
> > are still a little (/me tries to think of a relatively neutral term)...
> > wanting. :(
>
> But the reality of X is what we have to deal with.

And unix.

> This scheduler seems to close the corner cases of the interactivity
> estimator, but this "any background load is palpable" thing is decidedly
> detrimental to interactive feel.

Now I think you're getting carried away because of your expectations from the 
previous scheduler and its woefully unfair treatment towards interactive 
tasks. Look at how you're loading up your poor P4 even with HT. You throw 2 
cpu hogs only gently niced at it on top of your interactive tasks. If you're 
happy to nice them +5, why not more? And you know as well as anyone that the 
2nd logical core only gives you ~25% more cpu power overall so you're asking 
too much of it. Let's not even talk about how lovely this will (not) be once 
SMT nice gets killed off come 2.6.21 and nice does less if "buyer beware" you 
chose to enable HT in your own words.

> When I looked into keeping interactive tasks responsive, I came to the
> conclusion that I just couldn't get there from here across the full
> spectrum of cpu usage without a scheduler hint.  Interactive feel is
> absolutely dependent upon unfairness in many cases, and targeting that
> unfairness gets it right where heuristics sometimes can't.

See above. Your expectations of what you should be able to do are simply 
skewed. Find what cpu balance you loved in the old one (and I believe it 
wasn't that much more cpu in favour of X if I recall correctly) and simply 
change the nice setting on your lame encoder - since you're already setting 
one anyway.

We simply cannot continue arguing that we should dish out unfairness in any 
manner any more. It will always come back and bite us where we don't want it. 
We are getting good interactive response with a fair scheduler yet you seem 
intent on overloading it to find fault with it.

> 	-Mike

-- 
-ck

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Mon, 2007-03-12 at 21:27 +1100, Con Kolivas wrote:
> On Monday 12 March 2007 20:38, Mike Galbraith wrote:
> > 
> Now I think you're getting carried away because of your expectations from the 
> previous scheduler and its woefully unfair treatment towards interactive 
> tasks. Look at how you're loading up your poor P4 even with HT. You throw 2 
> cpu hogs only gently niced at it on top of your interactive tasks. If you're 
> happy to nice them +5, why not more? And you know as well as anyone that the 
> 2nd logical core only gives you ~25% more cpu power overall so you're asking 
> too much of it. Let's not even talk about how lovely this will (not) be once 
> SMT nice gets killed off come 2.6.21 and nice does less if "buyer beware" you 
> chose to enable HT in your own words.

The test scenario was one any desktop user might do with every
expectation responsiveness of the interactive application remain intact.
I understand the concepts here Con, and I'm not knocking your scheduler.
I find it to be a step forward on the one hand, but a step backward on
the other.

Tossing in the SMT nice comment was utter bullshit.  All kernels tested
were missing SMT nice.

> > When I looked into keeping interactive tasks responsive, I came to the
> > conclusion that I just couldn't get there from here across the full
> > spectrum of cpu usage without a scheduler hint.  Interactive feel is
> > absolutely dependent upon unfairness in many cases, and targeting that
> > unfairness gets it right where heuristics sometimes can't.
> 
> See above. Your expectations of what you should be able to do are simply 
> skewed. Find what cpu balance you loved in the old one (and I believe it 
> wasn't that much more cpu in favour of X if I recall correctly) and simply 
> change the nice setting on your lame encoder - since you're already setting 
> one anyway.
> 
> We simply cannot continue arguing that we should dish out unfairness in any 
> manner any more. It will always come back and bite us where we don't want it.

Unless you target accurately.

> We are getting good interactive response with a fair scheduler yet you seem 
> intent on overloading it to find fault with it.

I'm not trying to find fault, I'm TESTING AND REPORTING.  Was.

	bye,

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Ingo Molnar]

* Mike Galbraith <efault@gmx.de> wrote:

> The test scenario was one any desktop user might do with every 
> expectation responsiveness of the interactive application remain 
> intact. I understand the concepts here Con, and I'm not knocking your 
> scheduler. I find it to be a step forward on the one hand, but a step 
> backward on the other.

ok, then that step backward needs to be fixed.

> > We are getting good interactive response with a fair scheduler yet 
> > you seem intent on overloading it to find fault with it.
> 
> I'm not trying to find fault, I'm TESTING AND REPORTING.  Was.

Con, could you please take Mike's report of this regression seriously 
and address it? Thanks,

	Ingo

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On Monday 12 March 2007 22:08, Ingo Molnar wrote:
> * Mike Galbraith <efault@gmx.de> wrote:
> > The test scenario was one any desktop user might do with every
> > expectation responsiveness of the interactive application remain
> > intact. I understand the concepts here Con, and I'm not knocking your
> > scheduler. I find it to be a step forward on the one hand, but a step
> > backward on the other.
>
> ok, then that step backward needs to be fixed.
>
> > > We are getting good interactive response with a fair scheduler yet
> > > you seem intent on overloading it to find fault with it.
> >
> > I'm not trying to find fault, I'm TESTING AND REPORTING.  Was.
>
> Con, could you please take Mike's report of this regression seriously
> and address it? Thanks,

Sure. 

Mike the cpu is being proportioned out perfectly according to fairness as I 
mentioned in the prior email, yet X is getting the lower latency scheduling. 
I'm not sure within the bounds of fairness what more would you have happen to 
your liking with this test case?

-- 
-ck

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Theodore Tso]

On Mon, Mar 12, 2007 at 10:23:06PM +1100, Con Kolivas wrote:
> > > > We are getting good interactive response with a fair scheduler yet
> > > > you seem intent on overloading it to find fault with it.
> > >
> > > I'm not trying to find fault, I'm TESTING AND REPORTING.  Was.
> >
> > Con, could you please take Mike's report of this regression seriously
> > and address it? Thanks,
> 
> Sure. 
> 
> Mike the cpu is being proportioned out perfectly according to fairness as I 
> mentioned in the prior email, yet X is getting the lower latency scheduling. 
> I'm not sure within the bounds of fairness what more would you have happen 
> to your liking with this test case?

Con,

	I think what we're discovering is that a "fair scheduler" is
not going to cut it.  After all, running X and ripping CD's and MP3
encoding them is not exactly an esoteric use case.  And like it or
not, "nice" defaults to 4.

	I suspect Mike is right; the only way to deal with this
regression is some scheduler hints from the desktop subsystem (i.e., X
and friends).  Yes, X is broken, it's horrible, yadda, yadda, yadda.
It's also what everyone is using, and it's a fact of life.  Just like
we occasionally have had to work around ISA braindamage, and x86
architecture braindamage, and ACPI braindamage all inflicted on us by
Intel.  This is just life, and sometimes the clean, elegant solution
is not enough.

	Regards,

						- Ted

P.S.  The other solution that might perhaps work is that we need to
change the meaning of what the nice value does.  If we consider "nice"
to be the scheduler hint (from the other direction), then maybe any
niced process should only run a very tiny amount if there are any
non-nice processes ready to run, and that the relative nice values are
used when two niced processes are competing for the CPU.....

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On Tuesday 13 March 2007 00:48, Theodore Tso wrote:
> On Mon, Mar 12, 2007 at 10:23:06PM +1100, Con Kolivas wrote:
> > > > > We are getting good interactive response with a fair scheduler yet
> > > > > you seem intent on overloading it to find fault with it.
> > > >
> > > > I'm not trying to find fault, I'm TESTING AND REPORTING.  Was.
> > >
> > > Con, could you please take Mike's report of this regression seriously
> > > and address it? Thanks,
> >
> > Sure.
> >
> > Mike the cpu is being proportioned out perfectly according to fairness as
> > I mentioned in the prior email, yet X is getting the lower latency
> > scheduling. I'm not sure within the bounds of fairness what more would
> > you have happen to your liking with this test case?
>
> Con,
>
> 	I think what we're discovering is that a "fair scheduler" is
> not going to cut it.  After all, running X and ripping CD's and MP3
> encoding them is not exactly an esoteric use case.  And like it or
> not, "nice" defaults to 4.
>
> 	I suspect Mike is right; the only way to deal with this
> regression is some scheduler hints from the desktop subsystem (i.e., X
> and friends).  Yes, X is broken, it's horrible, yadda, yadda, yadda.
> It's also what everyone is using, and it's a fact of life.  Just like
> we occasionally have had to work around ISA braindamage, and x86
> architecture braindamage, and ACPI braindamage all inflicted on us by
> Intel.  This is just life, and sometimes the clean, elegant solution
> is not enough.

Instead of assuming it's bad, have you tried RSDL for yourself? Mike is using 
2 lame threads for his test case.

-- 
-ck

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:

> Mike the cpu is being proportioned out perfectly according to fairness as I 
> mentioned in the prior email, yet X is getting the lower latency scheduling. 
> I'm not sure within the bounds of fairness what more would you have happen to 
> your liking with this test case?

It has been said that "perfection is the enemy of good".  The two
interactive tasks receiving 40% cpu while two niced background jobs
receive 60% may well be perfect, but it's damn sure not good.

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Linus Torvalds]

On Mon, 12 Mar 2007, Mike Galbraith wrote:
>
> On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> 
> > Mike the cpu is being proportioned out perfectly according to fairness as I 
> > mentioned in the prior email, yet X is getting the lower latency scheduling. 
> > I'm not sure within the bounds of fairness what more would you have happen to 
> > your liking with this test case?
> 
> It has been said that "perfection is the enemy of good".  The two
> interactive tasks receiving 40% cpu while two niced background jobs
> receive 60% may well be perfect, but it's damn sure not good.

Well, the real problem is really "server that works on behalf of somebody 
else".

X is just the worst *practical* example of this, since not only is it the 
most common such server, it's also a case where people see interactive 
issues really easily.

And the problem is that a lot of clients actually end up doing *more* in 
the X server than they do themselves directly. Doing things like showing a 
line of text on the screen is a lot more expensive than just keeping track 
of that line of text, so you end up with the X server easily being marked 
as getting "too much" CPU time, and the clients as being starved for CPU 
time. And then you get bad interactive behaviour.

So "good fairness" really should involve some notion of "work done for 
others". It's just not very easy to do..

			Linus

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On Tuesday 13 March 2007 02:26, Linus Torvalds wrote:
> On Mon, 12 Mar 2007, Mike Galbraith wrote:
> > On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> > > Mike the cpu is being proportioned out perfectly according to fairness
> > > as I mentioned in the prior email, yet X is getting the lower latency
> > > scheduling. I'm not sure within the bounds of fairness what more would
> > > you have happen to your liking with this test case?
> >
> > It has been said that "perfection is the enemy of good".  The two
> > interactive tasks receiving 40% cpu while two niced background jobs
> > receive 60% may well be perfect, but it's damn sure not good.
>
> Well, the real problem is really "server that works on behalf of somebody
> else".
>
> X is just the worst *practical* example of this, since not only is it the
> most common such server, it's also a case where people see interactive
> issues really easily.
>
> And the problem is that a lot of clients actually end up doing *more* in
> the X server than they do themselves directly. Doing things like showing a
> line of text on the screen is a lot more expensive than just keeping track
> of that line of text, so you end up with the X server easily being marked
> as getting "too much" CPU time, and the clients as being starved for CPU
> time. And then you get bad interactive behaviour.
>
> So "good fairness" really should involve some notion of "work done for
> others". It's just not very easy to do..

Instead of assuming it's bad, have you tried RSDL for yourself? Mike is using 
2 lame threads for his test case.

-- 
-ck

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Peter Zijlstra]

On Mon, 2007-03-12 at 08:26 -0700, Linus Torvalds wrote:

> So "good fairness" really should involve some notion of "work done for 
> others". It's just not very easy to do..

A solution that is already in demand is a class based scheduler, where
the thread doing work for a client (temp.) joins the class of the
client.

The in-kernel virtualization guys also want to have this, for pretty
much the same reasons.

Peter

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Mon, 2007-03-12 at 08:26 -0700, Linus Torvalds wrote:
> 
> On Mon, 12 Mar 2007, Mike Galbraith wrote:
> >
> > On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> > 
> > > Mike the cpu is being proportioned out perfectly according to fairness as I 
> > > mentioned in the prior email, yet X is getting the lower latency scheduling. 
> > > I'm not sure within the bounds of fairness what more would you have happen to 
> > > your liking with this test case?
> > 
> > It has been said that "perfection is the enemy of good".  The two
> > interactive tasks receiving 40% cpu while two niced background jobs
> > receive 60% may well be perfect, but it's damn sure not good.
> 
> Well, the real problem is really "server that works on behalf of somebody 
> else".

Yes, exactly.  We have a disconnect.  The process consists of both.  If
either client or server doesn't get enough, the process is a failure.

> X is just the worst *practical* example of this, since not only is it the 
> most common such server, it's also a case where people see interactive 
> issues really easily.
> 
> And the problem is that a lot of clients actually end up doing *more* in 
> the X server than they do themselves directly. Doing things like showing a 
> line of text on the screen is a lot more expensive than just keeping track 
> of that line of text, so you end up with the X server easily being marked 
> as getting "too much" CPU time, and the clients as being starved for CPU 
> time. And then you get bad interactive behaviour.
> 
> So "good fairness" really should involve some notion of "work done for 
> others". It's just not very easy to do..

Purely from the interactivity side, I connected via a simple tag X as
TASK_INTERACTIVE thingy, and boosted the tasks it was waking.  Worked
for things like the heavy cpu visualizations while other things are
going on in the background.  It was full of evilness though.

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Kyle Moffett]

On Mar 12, 2007, at 11:26:25, Linus Torvalds wrote:
> So "good fairness" really should involve some notion of "work done  
> for others". It's just not very easy to do..

Maybe extend UNIX sockets to add another passable object type vis-a- 
vis SCM_RIGHTS, except in this case "SCM_CPUTIME".  You call  
SCM_CPUTIME with a time value in monotonic real-time nanoseconds  
(duration) and a value out of 100 indicating what percentage of your  
timeslices to give to the process (for the specified duration).  The  
receiving process would be informed of the estimated total number of  
nanoseconds of timeslice that it will be given based on the priority  
of the processes. (Maybe it could prioritize requests?).  The X  
libraries could then properly "pass" CPU time to the X server to help  
with rendering their requests, and the X server could give priority  
to tasks which give up more CPU time than is needed to render their  
data, and penalize those which use more than they give.  Initially  
even if you don't patch the X server you could at least patch the X  
clients to give up CPU to the X server to promote interactivity.

Cheers,
Kyle Moffett

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> > It has been said that "perfection is the enemy of good".  The two 
> > interactive tasks receiving 40% cpu while two niced background jobs 
> > receive 60% may well be perfect, but it's damn sure not good.
> 
> Well, the real problem is really "server that works on behalf of 
> somebody else".

i think Mike's testcase was even simpler than that: two plain CPU hogs 
on nice +5 stole much more CPU time with Con's new interactivity code 
than they did with the current interactivity code. I'd agree with Mike 
that a phenomenon like that needs to be fixed.

/less/ interactivity we can do easily in the current scheduler: just 
remove various bits here and there. The RSDL promise is that it gives us 
/more/ interactivity (with 'interactivity designed in', etc.), which in 
Mike's testcase does not seem to be the case.

> And the problem is that a lot of clients actually end up doing *more* 
> in the X server than they do themselves directly.

yeah. It's a hard case because X is not always a _clear_ interactive 
task - still the current interactivity code handles it quite well.

but Mike's scenario wasnt even that complex. It wasnt even a hard case 
of X being starved by _other_ interactive tasks running on the same nice 
level. Mike's test-scenario was about two plain nice +5 CPU hogs 
starving nice +0 interactive tasks more than the current scheduler does, 
and this is really not an area where we want to see any regression. Con, 
could you work on this area a bit more?

	Ingo

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On Tuesday 13 March 2007 01:34, Mike Galbraith wrote:
> On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> > Mike the cpu is being proportioned out perfectly according to fairness as
> > I mentioned in the prior email, yet X is getting the lower latency
> > scheduling. I'm not sure within the bounds of fairness what more would
> > you have happen to your liking with this test case?
>
> It has been said that "perfection is the enemy of good".  The two
> interactive tasks receiving 40% cpu while two niced background jobs
> receive 60% may well be perfect, but it's damn sure not good.

Again I think your test is not a valid testcase. Why use two threads for your 
encoding with one cpu? Is that what other dedicated desktop OSs would do?

And let's not lose sight of things with this one testcase.

RSDL fixes
- every starvation case
- all fairness isssues
- is better 95% of the time on the desktop

If we fix 95% of the desktop and worsen 5% is that bad given how much else 
we've gained in the process?

Anyway for my next trick I plan to make -nice values not suck again. So we can 
go full circle and start renicing X (only if you so desire) as well like we 
used to. I figure that's the only way left to satisfy all requirements to 
beat even those last 5%. However for the most part I don't even think 
renicing X will be required (and hasn't been prior to this testcase). 
Nonetheless unsucking negative nice values is probably worthwhile. 

I need time to make it so though. Precious sleep and mood has been destroyed 
this week.

-- 
-ck

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Xavier Bestel]

Le mardi 13 mars 2007 à 05:49 +1100, Con Kolivas a écrit :
> Again I think your test is not a valid testcase. Why use two threads for your 
> encoding with one cpu? Is that what other dedicated desktop OSs would do?

One thought occured to me (shit happens, sometimes): as your scheduler
is "strictly fair", won't that enable trivial DoS by just letting an
user fork a multitude of CPU-intensive processes ?

	Xav

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

On Mon, 12 Mar 2007 20:06:43 BST, Xavier Bestel said:
> Le mardi 13 mars 2007 à 05:49 +1100, Con Kolivas a écrit :
> > Again I think your test is not a valid testcase. Why use two threads for your 
> > encoding with one cpu? Is that what other dedicated desktop OSs would do?
> 
> One thought occured to me (shit happens, sometimes): as your scheduler
> is "strictly fair", won't that enable trivial DoS by just letting an
> user fork a multitude of CPU-intensive processes ?

Fork bombs are the reason that 'ulimit -u' exists. I don't see this scheduler
as being significantly more DoS'able via that route than previous schedulers.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Tue, 2007-03-13 at 05:49 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 01:34, Mike Galbraith wrote:
> > On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> > > Mike the cpu is being proportioned out perfectly according to fairness as
> > > I mentioned in the prior email, yet X is getting the lower latency
> > > scheduling. I'm not sure within the bounds of fairness what more would
> > > you have happen to your liking with this test case?
> >
> > It has been said that "perfection is the enemy of good".  The two
> > interactive tasks receiving 40% cpu while two niced background jobs
> > receive 60% may well be perfect, but it's damn sure not good.
> 
> Again I think your test is not a valid testcase. Why use two threads for your 
> encoding with one cpu? Is that what other dedicated desktop OSs would do?

The testcase is perfectly valid.  My buddies box has two full cores, so
we used two encoders such that whatever bandwidth is not being actively
consumed by more important things gets translated into mp3 encoding.

How would you go about ensuring that there won't be any cycles wasted?
 
_My_ box has 1 core that if fully utilized translates to 1.2 cores.. or
whatever, depending on the phase of the moon.  But no matter, logical vs
physical cpu argument is pure hand-waving.  What really matters here is
the bottom line: your fair scheduler ignores the very real requirements
of interactivity.

> And let's not lose sight of things with this one testcase.
> 
> RSDL fixes
> - every starvation case
> - all fairness isssues
> - is better 95% of the time on the desktop

I don't know where you got that 95% number from.  For the most part, the
existing scheduler does well.  If it sucked 95% of the time, it would
have been shredded a long time ago.

> If we fix 95% of the desktop and worsen 5% is that bad given how much else 
> we've gained in the process?

Killing the known corner case starvation scenarios is wonderful, but
let's not just pretend that interactive tasks don't have any special
requirements.

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On Tuesday 13 March 2007 07:11, Mike Galbraith wrote:
> On Tue, 2007-03-13 at 05:49 +1100, Con Kolivas wrote:
> > On Tuesday 13 March 2007 01:34, Mike Galbraith wrote:
> > > On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> > > > Mike the cpu is being proportioned out perfectly according to
> > > > fairness as I mentioned in the prior email, yet X is getting the
> > > > lower latency scheduling. I'm not sure within the bounds of fairness
> > > > what more would you have happen to your liking with this test case?
> > >
> > > It has been said that "perfection is the enemy of good".  The two
> > > interactive tasks receiving 40% cpu while two niced background jobs
> > > receive 60% may well be perfect, but it's damn sure not good.
> >
> > Again I think your test is not a valid testcase. Why use two threads for
> > your encoding with one cpu? Is that what other dedicated desktop OSs
> > would do?
>
> The testcase is perfectly valid.  My buddies box has two full cores, so
> we used two encoders such that whatever bandwidth is not being actively
> consumed by more important things gets translated into mp3 encoding.
>
> How would you go about ensuring that there won't be any cycles wasted?
>
> _My_ box has 1 core that if fully utilized translates to 1.2 cores.. or
> whatever, depending on the phase of the moon.  But no matter, logical vs
> physical cpu argument is pure hand-waving.  What really matters here is
> the bottom line: your fair scheduler ignores the very real requirements
> of interactivity.

Definitely not. It does not give unfair cpu towards interactive tasks. That's 
a very different argument.

> > And let's not lose sight of things with this one testcase.
> >
> > RSDL fixes
> > - every starvation case
> > - all fairness isssues
> > - is better 95% of the time on the desktop
>
> I don't know where you got that 95% number from.  For the most part, the
> existing scheduler does well.  If it sucked 95% of the time, it would
> have been shredded a long time ago.

Check the number of feedback reports. I don't feel petty enough to count them 
personally to give you an accuracte percentage.

> > If we fix 95% of the desktop and worsen 5% is that bad given how much
> > else we've gained in the process?
>
> Killing the known corner case starvation scenarios is wonderful, but
> let's not just pretend that interactive tasks don't have any special
> requirements.

Now you're really making a stretch of things. Where on earth did I say that 
interactive tasks don't have special requirements? It's a fundamental feature 
of this scheduler that I go to great pains to get them as low latency as 
possible and their fair share of cpu despite having a completely fair cpu 
distribution.

> 	-Mike

-- 
-ck

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Tue, 2007-03-13 at 07:38 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 07:11, Mike Galbraith wrote:
> >
> > Killing the known corner case starvation scenarios is wonderful, but
> > let's not just pretend that interactive tasks don't have any special
> > requirements.
> 
> Now you're really making a stretch of things. Where on earth did I say that 
> interactive tasks don't have special requirements? It's a fundamental feature 
> of this scheduler that I go to great pains to get them as low latency as 
> possible and their fair share of cpu despite having a completely fair cpu 
> distribution.

As soon as your cpu is fully utilized, fairness looses or interactivity
loses.  Pick one.

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On 13/03/07, Mike Galbraith <efault@gmx.de> wrote:
> On Tue, 2007-03-13 at 07:38 +1100, Con Kolivas wrote:
> > On Tuesday 13 March 2007 07:11, Mike Galbraith wrote:
> > >
> > > Killing the known corner case starvation scenarios is wonderful, but
> > > let's not just pretend that interactive tasks don't have any special
> > > requirements.
> >
> > Now you're really making a stretch of things. Where on earth did I say that
> > interactive tasks don't have special requirements? It's a fundamental feature
> > of this scheduler that I go to great pains to get them as low latency as
> > possible and their fair share of cpu despite having a completely fair cpu
> > distribution.
>
> As soon as your cpu is fully utilized, fairness looses or interactivity
> loses.  Pick one.

That's not true unless you refuse to prioritise your tasks
accordingly. Let's take this discussion in a different direction. You
already nice your lame processes. Why? You already have the concept
that you are prioritising things to normal or background tasks. You
say so yourself that lame is a background task. Stating the bleedingly
obvious, the unix way of prioritising things is via nice. You already
do that. So moving on from that...

Your test case you ask "how can I maximise cpu usage". Well you know
the answer already. You run two threads. I won't dispute that.

The debate seems to be centered on whether two tasks that are niced +5
or to a higher value is background. In my opinion, nice 5 is not
background, but relatively less cpu. You already are savvy enough to
be using two threads and nicing them. All I ask you to do when using
RSDL is to change your expectations slightly and your settings from
nice 5 to nice 10 or 15 or even 19. Why is that so offensive to you?
nice 5 is 75% the cpu of nice 0. nice 10 is 50%, nice 15 is 25%, nice
19 is 5%.If you're so intent on defining nice 5 as background would it
be a matter of me just modifying nice 5 to be 25% instead? I suspect
your answer will be no because then you'll argue that you shouldn't
nice at all, but it should be interesting to see your response. You
seem to be advocating that the scheduler does everything and we need
to implement some complex flag instead. I don't believe that's the
right thing to do at all. So I offer you some options.

1. Be happy with changing your nice from 5 to15. I still don't think
this is in any way unreasonable.
2. Wait for me to fix -niced tasks behaviour and -nice your X. I plan
to implement this change anyway, not necessarily for X.
3. Have me redefine what nice 5 is, and tell me what percentage cpu
you think is right.
4. Any combination of the above.

Please don't pick 5.none of the above. Please try to work with me on this.

--
-ck

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Tue, 2007-03-13 at 09:51 +1100, Con Kolivas wrote:
> On 13/03/07, Mike Galbraith <efault@gmx.de> wrote:

> > As soon as your cpu is fully utilized, fairness looses or interactivity
> > loses.  Pick one.
> 
> That's not true unless you refuse to prioritise your tasks
> accordingly. Let's take this discussion in a different direction. You
> already nice your lame processes. Why? You already have the concept
> that you are prioritising things to normal or background tasks. You
> say so yourself that lame is a background task. Stating the bleedingly
> obvious, the unix way of prioritising things is via nice. You already
> do that. So moving on from that...

Sure.  If a user wants to do anything interactive, they can indeed nice
19 the rest of their box before they start.

> Your test case you ask "how can I maximise cpu usage". Well you know
> the answer already. You run two threads. I won't dispute that.
> 
> The debate seems to be centered on whether two tasks that are niced +5
> or to a higher value is background. In my opinion, nice 5 is not
> background, but relatively less cpu. You already are savvy enough to
> be using two threads and nicing them. All I ask you to do when using
> RSDL is to change your expectations slightly and your settings from
> nice 5 to nice 10 or 15 or even 19. Why is that so offensive to you?

It's not "offensive" to me, it is a behavioral regression.  The
situation as we speak is that you can run cpu intensive tasks while
watching eye-candy.  With RSDL, you can't, you feel the non-interactive
load instantly.  Doesn't the fact that you're asking me to lower my
expectations tell you that I just might have a point?

> Please don't pick 5.none of the above. Please try to work with me on this.

I'm not trying to be pig-headed.  I'm of the opinion that fairness is
great... until you strictly enforce it wrt interactive tasks.  

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On Tuesday 13 March 2007 16:10, Mike Galbraith wrote:
> On Tue, 2007-03-13 at 09:51 +1100, Con Kolivas wrote:
> > On 13/03/07, Mike Galbraith <efault@gmx.de> wrote:
> > > As soon as your cpu is fully utilized, fairness looses or interactivity
> > > loses.  Pick one.
> >
> > That's not true unless you refuse to prioritise your tasks
> > accordingly. Let's take this discussion in a different direction. You
> > already nice your lame processes. Why? You already have the concept
> > that you are prioritising things to normal or background tasks. You
> > say so yourself that lame is a background task. Stating the bleedingly
> > obvious, the unix way of prioritising things is via nice. You already
> > do that. So moving on from that...
>
> Sure.  If a user wants to do anything interactive, they can indeed nice
> 19 the rest of their box before they start.
>
> > Your test case you ask "how can I maximise cpu usage". Well you know
> > the answer already. You run two threads. I won't dispute that.
> >
> > The debate seems to be centered on whether two tasks that are niced +5
> > or to a higher value is background. In my opinion, nice 5 is not
> > background, but relatively less cpu. You already are savvy enough to
> > be using two threads and nicing them. All I ask you to do when using
> > RSDL is to change your expectations slightly and your settings from
> > nice 5 to nice 10 or 15 or even 19. Why is that so offensive to you?
>
> It's not "offensive" to me, it is a behavioral regression.  The
> situation as we speak is that you can run cpu intensive tasks while
> watching eye-candy.  With RSDL, you can't, you feel the non-interactive
> load instantly.  Doesn't the fact that you're asking me to lower my
> expectations tell you that I just might have a point?

Yet looking at the mainline scheduler code, nice 5 tasks are also supposed to 
get 75% cpu compared to nice 0 tasks, however I cannot seem to get 75% cpu 
with a fully cpu bound task in the presence of an interactive task. To me 
that means mainline is not living up to my expectations. What you're saying 
is your expectations are based on a false cpu expectation from nice 5. You 
can spin it both ways. It seems to me the only one that lives up to a defined 
expectation is to be fair. Anything else is at best vague, and at worst 
starvation prone.

> > Please don't pick 5.none of the above. Please try to work with me on
> > this.
>
> I'm not trying to be pig-headed.  I'm of the opinion that fairness is
> great... until you strictly enforce it wrt interactive tasks.

How about answering my question then since I offered you numerous combinations 
of ways to tackle the problem? The simplest one doesn't even need code, it 
just needs you to alter the nice value that you're already setting.

-- 
-ck

Re: [ck] Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Rodney Gordon II]

On Tuesday 13 March 2007 00:53, Con Kolivas wrote:
> On Tuesday 13 March 2007 16:10, Mike Galbraith wrote:
> > On Tue, 2007-03-13 at 09:51 +1100, Con Kolivas wrote:
> > > On 13/03/07, Mike Galbraith <efault@gmx.de> wrote:
> > > > As soon as your cpu is fully utilized, fairness looses or
> > > > interactivity loses.  Pick one.
> > >
> > > That's not true unless you refuse to prioritise your tasks
> > > accordingly. Let's take this discussion in a different direction. You
> > > already nice your lame processes. Why? You already have the concept
> > > that you are prioritising things to normal or background tasks. You
> > > say so yourself that lame is a background task. Stating the bleedingly
> > > obvious, the unix way of prioritising things is via nice. You already
> > > do that. So moving on from that...
> >
> > Sure.  If a user wants to do anything interactive, they can indeed nice
> > 19 the rest of their box before they start.
> >
> > > Your test case you ask "how can I maximise cpu usage". Well you know
> > > the answer already. You run two threads. I won't dispute that.
> > >
> > > The debate seems to be centered on whether two tasks that are niced +5
> > > or to a higher value is background. In my opinion, nice 5 is not
> > > background, but relatively less cpu. You already are savvy enough to
> > > be using two threads and nicing them. All I ask you to do when using
> > > RSDL is to change your expectations slightly and your settings from
> > > nice 5 to nice 10 or 15 or even 19. Why is that so offensive to you?
> >
> > It's not "offensive" to me, it is a behavioral regression.  The
> > situation as we speak is that you can run cpu intensive tasks while
> > watching eye-candy.  With RSDL, you can't, you feel the non-interactive
> > load instantly.  Doesn't the fact that you're asking me to lower my
> > expectations tell you that I just might have a point?

I do not feel nearly any non-interactive load. See below.

>
> Yet looking at the mainline scheduler code, nice 5 tasks are also supposed
> to get 75% cpu compared to nice 0 tasks, however I cannot seem to get 75%
> cpu with a fully cpu bound task in the presence of an interactive task. To
> me that means mainline is not living up to my expectations. What you're
> saying is your expectations are based on a false cpu expectation from nice
> 5. You can spin it both ways. It seems to me the only one that lives up to
> a defined expectation is to be fair. Anything else is at best vague, and at
> worst starvation prone.
>
> > > Please don't pick 5.none of the above. Please try to work with me on
> > > this.
> >
> > I'm not trying to be pig-headed.  I'm of the opinion that fairness is
> > great... until you strictly enforce it wrt interactive tasks.
>
> How about answering my question then since I offered you numerous
> combinations of ways to tackle the problem? The simplest one doesn't even
> need code, it just needs you to alter the nice value that you're already
> setting.

Also, just to chime in, I am doing a large project converting over 250GB of 
FLAC audio to MP3 via lame for my archive conversion.

I am using 2.6.20.2-rsdl0.30, and I have 2 processes of flac decoding/lame 
encoding running simultaneously from a perl script I hacked up on my P-D 830. 
These processes are both nice'd to 19.

I have almost no degredation in latency in my usage of X (which is at nice 0), 
if that matters at all. Please try what Con is suggesting by adjusting your 
nice level, and see if that helps you at all.

These are just useless arguments, time better spent on coding and fixing real 
problems, than a flamewar on whether nice 5 is good enough or not.

Con's rsdl implements what ingosched was supposed to do, wrt the niceness 
levels. Perhaps Mike, you are used to the impression ingosched gave you with 
nice +5, but try something else as Con suggested.. +10, +15, hell, whatever. 
Is that so hard?

My 2c,
-r

-- 
Rodney "meff" Gordon II -*- meff@pobox.com
Systems Administrator / Coder Geek -*- Open yourself to OpenSource

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Tue, 2007-03-13 at 16:53 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 16:10, Mike Galbraith wrote:

> > I'm not trying to be pig-headed.  I'm of the opinion that fairness is
> > great... until you strictly enforce it wrt interactive tasks.
> 
> How about answering my question then since I offered you numerous combinations 
> of ways to tackle the problem? The simplest one doesn't even need code, it 
> just needs you to alter the nice value that you're already setting.

Hey, you specifically asked me to not choose 5 :)  (I mentioned 5
earlier in the thread anyway, so no sense in repeating myself)

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Tue, 2007-03-13 at 16:53 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 16:10, Mike Galbraith wrote:

> > It's not "offensive" to me, it is a behavioral regression.  The
> > situation as we speak is that you can run cpu intensive tasks while
> > watching eye-candy.  With RSDL, you can't, you feel the non-interactive
> > load instantly.  Doesn't the fact that you're asking me to lower my
> > expectations tell you that I just might have a point?
> 
> Yet looking at the mainline scheduler code, nice 5 tasks are also supposed to 
> get 75% cpu compared to nice 0 tasks, however I cannot seem to get 75% cpu 
> with a fully cpu bound task in the presence of an interactive task.

(One more comment before I go.  You can then have the last word this
time, promise :)

Because the interactivity logic, which was put there to do precisely
this, is doing it's job?

>  To me 
> that means mainline is not living up to my expectations. What you're saying 
> is your expectations are based on a false cpu expectation from nice 5. You 
> can spin it both ways.

Talk about spin, you turn an example of the current scheduler working
properly into a negative attribute, and attempt to discredit me with it.

The floor is yours.  No reply will be forthcoming.

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Ingo Molnar]

* Con Kolivas <kernel@kolivas.org> wrote:

> > It's not "offensive" to me, it is a behavioral regression.  The 
> > situation as we speak is that you can run cpu intensive tasks while 
> > watching eye-candy.  With RSDL, you can't, you feel the 
> > non-interactive load instantly.  Doesn't the fact that you're asking 
> > me to lower my expectations tell you that I just might have a point?
> 
> Yet looking at the mainline scheduler code, nice 5 tasks are also 
> supposed to get 75% cpu compared to nice 0 tasks, however I cannot 
> seem to get 75% cpu with a fully cpu bound task in the presence of an 
> interactive task. [...]

i'm sorry, but your argument seems to be negated. We of course have no 
problem with interactive tasks stealing CPU time from CPU hogs. The 
situation Mike found is _the other direction_: that /CPU hogs/ stole 
from interactive tasks. That's bad and needs to be fixed. Please?

	Ingo

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Ingo Molnar]

* Mike Galbraith <efault@gmx.de> wrote:

> [...] The situation as we speak is that you can run cpu intensive 
> tasks while watching eye-candy.  With RSDL, you can't, you feel the 
> non-interactive load instantly. [...]

i have to agree with Mike that this is a material regression that cannot 
be talked around.

Con, we want RSDL to /improve/ interactivity. Having new scheduler 
interactivity logic that behaves /worse/ in the presence of CPU hogs, 
which CPU hogs are even reniced to +5, than the current interactivity 
code, is i think a non-starter. Could you try to fix this, please? Good 
interactivity in the presence of CPU hogs (be them default nice level or 
nice +5) is _the_ most important scheduler interactivity metric. 
Anything else is really secondary.

	Ingo

ps. please be nice to each other - both of you are long-time
    scheduler contributors who did lots of cool stuff :-)

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Tue, 2007-03-13 at 09:18 +0100, Ingo Molnar wrote:

> ps. please be nice to each other - both of you are long-time
>     scheduler contributors who did lots of cool stuff :-)

It's no big deal, Con and I just seem to be oil and water.  He'll have
to be oil, because water is already take.  *evaporate* :)

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On Tuesday 13 March 2007 19:18, Ingo Molnar wrote:
> * Mike Galbraith <efault@gmx.de> wrote:
> > [...] The situation as we speak is that you can run cpu intensive
> > tasks while watching eye-candy.  With RSDL, you can't, you feel the
> > non-interactive load instantly. [...]
>
> i have to agree with Mike that this is a material regression that cannot
> be talked around.
>
> Con, we want RSDL to /improve/ interactivity. Having new scheduler
> interactivity logic that behaves /worse/ in the presence of CPU hogs,
> which CPU hogs are even reniced to +5, than the current interactivity
> code, is i think a non-starter. Could you try to fix this, please? Good
> interactivity in the presence of CPU hogs (be them default nice level or
> nice +5) is _the_ most important scheduler interactivity metric.
> Anything else is really secondary.

Well I guess you must have missed where I asked him if he would be happy if I 
changed +5 metrics to do whatever he wanted and he refused to answer me. That 
would easily fit within that scheme. Any percentage of nice value he chose. I 
suggest 50% of nice 0. Heck I can even increase it if he likes. All I asked 
for was an answer as to whether that would satisfy his criterion.

> 	Ingo
>
> ps. please be nice to each other - both of you are long-time
>     scheduler contributors who did lots of cool stuff :-)

I have been civil. Only one email crossed the line on my part and I apologise.

-- 
-ck

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Ingo Molnar]

* Con Kolivas <kernel@kolivas.org> wrote:

> Well I guess you must have missed where I asked him if he would be 
> happy if I changed +5 metrics to do whatever he wanted and he refused 
> to answer me. [...]

I'd say lets keep nice levels out of this completely for now - while 
they should work _too_, it's easy because the scheduler has the 'nice' 
information. The basic behavior of CPU hogs that matters most.

So the question is: if all tasks are on the same nice level, how does, 
in Mike's test scenario, RSDL behave relative to the current 
interactivity code?

	Ingo

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On Tuesday 13 March 2007 20:29, Ingo Molnar wrote:
> * Con Kolivas <kernel@kolivas.org> wrote:
> > Well I guess you must have missed where I asked him if he would be
> > happy if I changed +5 metrics to do whatever he wanted and he refused
> > to answer me. [...]
>
> I'd say lets keep nice levels out of this completely for now - while
> they should work _too_, it's easy because the scheduler has the 'nice'
> information. The basic behavior of CPU hogs that matters most.
>
> So the question is: if all tasks are on the same nice level, how does,
> in Mike's test scenario, RSDL behave relative to the current
> interactivity code?

If everything is run at nice 0? (this was not the test case but that's what 
you've asked for).

We have:
X + GForce contribute a load of 1
lame x 2 threads contribute a load of 2

In RSDL
X + GForce will get 33% cpu
lame will get 66% cpu

In mainline
X + GForce gets a fluctuating percentage somewhere between 35~45% as far as I 
can see on UP.
lame gets the rest

The only way to get the same behaviour on RSDL without hacking an 
interactivity estimator, priority boost cpu misproportionator onto it is to 
either -nice X or +nice lame.

> 	Ingo

-- 
-ck

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Bill Huey]

On Tue, Mar 13, 2007 at 08:41:05PM +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 20:29, Ingo Molnar wrote:
> > So the question is: if all tasks are on the same nice level, how does,
> > in Mike's test scenario, RSDL behave relative to the current
> > interactivity code?
... 
> The only way to get the same behaviour on RSDL without hacking an 
> interactivity estimator, priority boost cpu misproportionator onto it is to 
> either -nice X or +nice lame.

Hello Ingo,

After talking to Con over IRC (and if I can summarize it), he's wondering if
properly nicing those tasks, as previously mention in user emails, would solve
this potential user reported regression or is something additional needed. It
seems like folks are happy with the results once the nice tweeking is done.
This is a huge behavior change after all to scheduler (just thinking out loud).

bill

Re: [ck] Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On Tuesday 13 March 2007 20:21, Con Kolivas wrote:
> On Tuesday 13 March 2007 19:18, Ingo Molnar wrote:
> > * Mike Galbraith <efault@gmx.de> wrote:
> > > [...] The situation as we speak is that you can run cpu intensive
> > > tasks while watching eye-candy.  With RSDL, you can't, you feel the
> > > non-interactive load instantly. [...]
> >
> > i have to agree with Mike that this is a material regression that cannot
> > be talked around.
> >
> > Con, we want RSDL to /improve/ interactivity. Having new scheduler
> > interactivity logic that behaves /worse/ in the presence of CPU hogs,
> > which CPU hogs are even reniced to +5, than the current interactivity
> > code, is i think a non-starter. Could you try to fix this, please? Good
> > interactivity in the presence of CPU hogs (be them default nice level or
> > nice +5) is _the_ most important scheduler interactivity metric.
> > Anything else is really secondary.
>
> Well I guess you must have missed where I asked him if he would be happy if
> I changed +5 metrics to do whatever he wanted and he refused to answer me.
> That would easily fit within that scheme. Any percentage of nice value he
> chose. I suggest 50% of nice 0. Heck I can even increase it if he likes.
> All I asked for was an answer as to whether that would satisfy his
> criterion.

It seem Mike has chosen to go silent so I'll guess on his part. 

nice on my debian etch seems to choose nice +10 without arguments contrary to 
a previous discussion that said 4 was the default. However 4 is a good value 
to use as a base of sorts.

What I propose is as a proportion of nice 0:
nice 4 1/2
nice 8 1/4
nice 12 1/8
nice 16 1/16
nice 20 1/32 (of course nice 20 doesn't exist)

and we can do the opposite in the other direction
nice -4 2
nice -8 4
nice -12 8
nice -16 16
nice -20 32

Assuming no further discussion is forthcoming I'll implement that along with 
Al's suggestion for staggering the latencies better with nice differences 
since the two are changing the same thing.

-- 
-ck

Re: [ck] Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Xavier Bestel]

On Tue, 2007-03-13 at 20:31 +1100, Con Kolivas wrote:
> nice on my debian etch seems to choose nice +10 without arguments contrary to 
> a previous discussion that said 4 was the default. However 4 is a good value 
> to use as a base of sorts.

I don't see why. nice uses +10 by default on all linux distro, and even
on Solaris and HP/UX. So I suspect that if Mike just used "nice lame"
instead of "nice +5 lame", he would have got what he wanted.

	Xav

Re: [ck] Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Sanjoy Mahajan]

> a previous discussion that said 4 was the default...I don't see
> why. nice uses +10 by default on all linux distro...So I suspect
> that if Mike just used "nice lame" instead of "nice +5 lame", he
> would have got what he wanted.

tcsh, and probably csh, has a builtin 'nice' with default +4.  So

  tcsh% nice ps -l

will show a process with nice +4.  If you tell it not to use the builtin,

  tcsh% \nice ps -l

then it uses /usr/bin/nice and you get +10.  bash doesn't have a nice
builtin, so it always uses /usr/bin/nice and you get +10 by default.

-Sanjoy

`Not all those who wander are lost.' (J.R.R. Tolkien)

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Tue, 2007-03-13 at 09:18 +0100, Ingo Molnar wrote:

> Con, we want RSDL to /improve/ interactivity. Having new scheduler 
> interactivity logic that behaves /worse/ in the presence of CPU hogs, 
> which CPU hogs are even reniced to +5, than the current interactivity 
> code, is i think a non-starter. Could you try to fix this, please? Good 
> interactivity in the presence of CPU hogs (be them default nice level or 
> nice +5) is _the_ most important scheduler interactivity metric. 
> Anything else is really secondary.

I just retested with the encoders at nice 0, and the x/gforce combo is
terrible.  Funny thing though, x/gforce isn't as badly affected with a
kernel build.  Any build is quite noticable, but even at -j8, the effect
doen't seem to be (very brief test warning applies) as bad as with only
the two encoders running.  That seems quite odd.

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Ingo Molnar]

* Mike Galbraith <efault@gmx.de> wrote:

> I just retested with the encoders at nice 0, and the x/gforce combo is 
> terrible. [...]

ok. So nice levels had nothing to do with it - it's some other 
regression somewhere. How does the vanilla scheduler cope with the 
exactly same workload? I.e. could you describe the 'delta' difference in 
behavior - because the delta is what we are interested in mostly, the 
'absolute' behavior alone is not sufficient. Something like:

 - on scheduler foo, under this workload, the CPU hogs steal 70% CPU 
   time and the resulting desktop experience is 'choppy': mouse pointer 
   is laggy and audio skips.

 - on scheduler bar, under this workload, the CPU hogs are at 40% 
   CPU time and the desktop experience is smooth.

things like that - we really need to be able to see the delta.

> [...]  Funny thing though, x/gforce isn't as badly affected with a 
> kernel build.  Any build is quite noticable, but even at -j8, the 
> effect doen't seem to be (very brief test warning applies) as bad as 
> with only the two encoders running.  That seems quite odd.

likewise, how does the RSDL kernel build behavior compare to the vanilla 
scheduler's behavior? (what happens in one that doesnt happen in the 
other, etc.)

	Ingo

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On Tuesday 13 March 2007 20:39, Ingo Molnar wrote:
> * Mike Galbraith <efault@gmx.de> wrote:
> > I just retested with the encoders at nice 0, and the x/gforce combo is
> > terrible. [...]
>
> ok. So nice levels had nothing to do with it - it's some other
> regression somewhere. How does the vanilla scheduler cope with the
> exactly same workload? I.e. could you describe the 'delta' difference in
> behavior - because the delta is what we are interested in mostly, the
> 'absolute' behavior alone is not sufficient. Something like:
>
>  - on scheduler foo, under this workload, the CPU hogs steal 70% CPU
>    time and the resulting desktop experience is 'choppy': mouse pointer
>    is laggy and audio skips.
>
>  - on scheduler bar, under this workload, the CPU hogs are at 40%
>    CPU time and the desktop experience is smooth.
>
> things like that - we really need to be able to see the delta.

I only find a slowdown, no choppiness, no audio stutter (it would be extremely 
hard to make audio stutter in this design without i/o starvation or something 
along those lines). The number difference in cpu percentage I've already 
given on the previous email. The graphics driver does feature in this test 
case as well so others' mileage may vary. Mike said it was terrible.

> > [...]  Funny thing though, x/gforce isn't as badly affected with a
> > kernel build.  Any build is quite noticable, but even at -j8, the
> > effect doen't seem to be (very brief test warning applies) as bad as
> > with only the two encoders running.  That seems quite odd.
>
> likewise, how does the RSDL kernel build behavior compare to the vanilla
> scheduler's behavior? (what happens in one that doesnt happen in the
> other, etc.)

Kernel compiles seem similar till the jobs get above about 3 where rsdl gets 
slower but still smooth. Audio is basically unaffected either way.

Don't forget all the rest of the cases people have posted.

-- 
-ck

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Tue, 2007-03-13 at 21:06 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 20:39, Ingo Molnar wrote:
> > * Mike Galbraith <efault@gmx.de> wrote:
> > > I just retested with the encoders at nice 0, and the x/gforce combo is
> > > terrible. [...]
> >
> > ok. So nice levels had nothing to do with it - it's some other
> > regression somewhere. How does the vanilla scheduler cope with the
> > exactly same workload? I.e. could you describe the 'delta' difference in
> > behavior - because the delta is what we are interested in mostly, the
> > 'absolute' behavior alone is not sufficient. Something like:
> >
> >  - on scheduler foo, under this workload, the CPU hogs steal 70% CPU
> >    time and the resulting desktop experience is 'choppy': mouse pointer
> >    is laggy and audio skips.
> >
> >  - on scheduler bar, under this workload, the CPU hogs are at 40%
> >    CPU time and the desktop experience is smooth.
> >
> > things like that - we really need to be able to see the delta.
> 
> I only find a slowdown, no choppiness, no audio stutter (it would be extremely 
> hard to make audio stutter in this design without i/o starvation or something 
> along those lines). The number difference in cpu percentage I've already 
> given on the previous email. The graphics driver does feature in this test 
> case as well so others' mileage may vary. Mike said it was terrible.

My first test run with lame at nice 0 was truly horrid, but has _not_
repeated, so disregard that as an anomaly.  For the most part, it is as
you say, things just get slower with load, any load.  I definitely am
seeing lurchiness which is not present in mainline.  No audio problems
with either kernel.

> > > [...]  Funny thing though, x/gforce isn't as badly affected with a
> > > kernel build.  Any build is quite noticable, but even at -j8, the
> > > effect doen't seem to be (very brief test warning applies) as bad as
> > > with only the two encoders running.  That seems quite odd.
> >
> > likewise, how does the RSDL kernel build behavior compare to the vanilla
> > scheduler's behavior? (what happens in one that doesnt happen in the
> > other, etc.)
> 
> Kernel compiles seem similar till the jobs get above about 3 where rsdl gets 
> slower but still smooth. Audio is basically unaffected either way.

It seems to be a plain linear slowdown.  The lurchiness I'm experiencing
varies in intensity, and is impossible to quantify.  I see neither
lurchiness nor slowdown in mainline through -j8.

> Don't forget all the rest of the cases people have posted.

Absolutely, all test results count.

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Serge Belyshev]

Mike Galbraith <efault@gmx.de> writes:

[snip]
> It seems to be a plain linear slowdown.  The lurchiness I'm experiencing
> varies in intensity, and is impossible to quantify.  I see neither
> lurchiness nor slowdown in mainline through -j8.
>
Whaa? make -j8 on mainline makes my desktop box completely useless.

Please reconsider your statement.

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Tue, 2007-03-13 at 14:41 +0300, Serge Belyshev wrote:
> Mike Galbraith <efault@gmx.de> writes:
> 
> [snip]
> > It seems to be a plain linear slowdown.  The lurchiness I'm experiencing
> > varies in intensity, and is impossible to quantify.  I see neither
> > lurchiness nor slowdown in mainline through -j8.
> >
> Whaa? make -j8 on mainline makes my desktop box completely useless.
> 
> Please reconsider your statement.

I'll do no such thing, and don't appreciate the insinuation.

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[John Stoffel]

>>>>> "Serge" == Serge Belyshev <belyshev@depni.sinp.msu.ru> writes:

Serge> Mike Galbraith <efault@gmx.de> writes:
Serge> [snip]
>> It seems to be a plain linear slowdown.  The lurchiness I'm experiencing
>> varies in intensity, and is impossible to quantify.  I see neither
>> lurchiness nor slowdown in mainline through -j8.
>> 

Serge> Whaa? make -j8 on mainline makes my desktop box completely
Serge> useless.

I tried a make -j5 on my Dual processor PIII Xeon box.  It was pretty
slow.  Firefox was ok scrolling with keyboard, but the scrollbar was
jerky.  I also has MP3s playing at the same time and it worked just
fine.  No drops that I heard. 

This is 2.6.21-rc3 patched with RSDL.  

To me, that large a load on my system was just pushing it too hard.
Esp since firefox seems to have become a total CPU hog in it's own
right lately.  Or is that because I have a Matrox G450 as my video
card and it's not handling GPU rendering in the card, but in the OS
these days?  I dunno...

I guess I need to reboot into the default scheduler and see how it
goes.  

Serge> Please reconsider your statement.

This is not a nice statement on your half.  Mike has been doing a
great job testing.  He and Con don't seem to communicate well at
times, but hey, they're still talking and working together, even with
friction.  I'm happy to see all this testing going on!

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Matt Mackall]

On Tue, Mar 13, 2007 at 10:33:18AM +0100, Mike Galbraith wrote:
> On Tue, 2007-03-13 at 09:18 +0100, Ingo Molnar wrote:
> 
> > Con, we want RSDL to /improve/ interactivity. Having new scheduler 
> > interactivity logic that behaves /worse/ in the presence of CPU hogs, 
> > which CPU hogs are even reniced to +5, than the current interactivity 
> > code, is i think a non-starter. Could you try to fix this, please? Good 
> > interactivity in the presence of CPU hogs (be them default nice level or 
> > nice +5) is _the_ most important scheduler interactivity metric. 
> > Anything else is really secondary.
> 
> I just retested with the encoders at nice 0, and the x/gforce combo is
> terrible.  Funny thing though, x/gforce isn't as badly affected with a
> kernel build.  Any build is quite noticable, but even at -j8, the effect
> doen't seem to be (very brief test warning applies) as bad as with only
> the two encoders running.  That seems quite odd.

Is gforce calling sched_yield?

Can you try testing with some simpler loads, like these:

memload:
#!/usr/bin/python
a = "a" * 16 * 1024 * 1024
while 1:
    b = a[1:] + "b"
    a = b[1:] + "c"

execload:
#!/bin/sh
exec ./execload

forkload:
#!/bin/sh
./forkload&

pipeload:
#!/usr/bin/python
import os
pi, po = os.pipe()
if os.fork():
  while 1:
    os.write(po, "A" * 4096)
else:
  while 1:
    os.read(pi, 4096)

-- 
Mathematics is the supreme nostalgia of our time.

RE: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[David Schwartz]

> * Mike Galbraith <efault@gmx.de> wrote:
>
> > [...] The situation as we speak is that you can run cpu intensive
> > tasks while watching eye-candy.  With RSDL, you can't, you feel the
> > non-interactive load instantly. [...]
>
> i have to agree with Mike that this is a material regression that cannot
> be talked around.

I don't know what else you can do when the argument is that behavior that is
wrong is what you actually want. The regression is not that the scheduler
doesn't do what it was asked to do or even that it isn't more faithful to
what it was told to do than the scheduler it replaces. The regression is
that the scheduler didn't do what Mike wanted it to do, even though he
didn't ask it to do that.

I would argue this is progression, not regression. The new scheduler is
fairer than the old one and fairness is good even though it sometimes hurts
some tasks.

> Con, we want RSDL to /improve/ interactivity.

Not when the interactivity was the result of unfairness.

> Having new scheduler
> interactivity logic that behaves /worse/ in the presence of CPU hogs,
> which CPU hogs are even reniced to +5, than the current interactivity
> code, is i think a non-starter. Could you try to fix this, please?

If you did this, it would mean that all the space between the signficant
level of unfairness you want in this case and pure fairness would have to
fit in five nice levels. That just seems like poor granularity.

> Good
> interactivity in the presence of CPU hogs (be them default nice level or
> nice +5) is _the_ most important scheduler interactivity metric.
> Anything else is really secondary.

Good interactivity for tasks that aren't themselves CPU hogs. A task should
get low latency if and only if it's yielding the CPU voluntarily most of the
time. If it's not, it can only get better interactivity at the cost of
fairness, and you have to *ask* for that. (Common sense says you can't give
a task *more* CPU because it yields the CPU a lot. And how else do you
determine interactivity other than nice level?)

This scheduler will not give you greater interactivity at the cost of
fairness unless you really ask for it. I think that's a good thing, though I
do agree it might take some getting used to.

I'm not saying it is impossible to make RSDL better at handling this
particular job. I'm saying the "regression" may be the scheduler doing what
it was asked to do more faithfully than the current scheduler and the right
fix (at least in the longer term) is to ask for what you really want.

DS

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Jeremy Fitzhardinge]

David Schwartz wrote:
> Good interactivity for tasks that aren't themselves CPU hogs. A task should
> get low latency if and only if it's yielding the CPU voluntarily most of the
> time. If it's not, it can only get better interactivity at the cost of
> fairness, and you have to *ask* for that. (Common sense says you can't give
> a task *more* CPU because it yields the CPU a lot. And how else do you
> determine interactivity other than nice level?)
>   

There's a distinction between giving it more cpu and giving it higher
priority: the important part about having high priority is getting low
latency access to the cpu when its needed.

> This scheduler will not give you greater interactivity at the cost of
> fairness unless you really ask for it. I think that's a good thing, though I
> do agree it might take some getting used to.
>   

This really seems like the wrong approach to me.  The implication here
and in other mails is that fairness is an inherently good thing which
should obviously take preference over any other property.

It's a nice simple stance, and its relatively easy to code up and test
to see that its working, but it doesn't really give people what they want.

The old unix-style dynamic priority scheme was designed to give
interactive processes high priorities, by using the observation that
"interactive" means "spends a lot of time blocked waiting for input". 
That model of interactive is way too simple now, and the attempts to try
an find an equivalent heuristic have been flawed and lead to - in some
cases - wildly bad behaviours.  I'm guessing the emphasis on "fairness"
is in reaction to this, which is fair enough.

But saying that the user needs to explicitly hold the schedulers hand
and nice everything to tell it how to schedule seems to be an abdication
of duty, an admission of failure.  We can't expect users to finesse all
their processes with nice, and it would be a bad user interface to ask
them to do so. 

And if someone/distro *does* go to all the effort of managing how to get
all the processes at the right nice levels, you have this big legacy
problem where you're now stuck keeping all those nice values meaningful
as you continue to develop the scheduler.  Its bad enough to make them
do the work in the first place, but its worse if they need to make it a
kernel version dependent function.

    J

RE: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[David Schwartz]

> There's a distinction between giving it more cpu and giving it higher
> priority: the important part about having high priority is getting low
> latency access to the cpu when its needed.

I agree. Tasks that voluntarily relinquish their timeslices should get lower
latency compared to other processes at the same static priority.

> This really seems like the wrong approach to me.  The implication here
> and in other mails is that fairness is an inherently good thing which
> should obviously take preference over any other property.

Yes, that is the implication. The alternative to fairness is arbitrary
unfairness. "Rational unfairness" is a form of fairness.

> The old unix-style dynamic priority scheme was designed to give
> interactive processes high priorities, by using the observation that
> "interactive" means "spends a lot of time blocked waiting for input".
> That model of interactive is way too simple now, and the attempts to try
> an find an equivalent heuristic have been flawed and lead to - in some
> cases - wildly bad behaviours.  I'm guessing the emphasis on "fairness"
> is in reaction to this, which is fair enough.

I don't think it makes sense for the scheduler to look for some hint that
the user would prefer a task to get more CPU and try to give it more. That's
what 'nice' is for.

> But saying that the user needs to explicitly hold the schedulers hand
> and nice everything to tell it how to schedule seems to be an abdication
> of duty, an admission of failure.  We can't expect users to finesse all
> their processes with nice, and it would be a bad user interface to ask
> them to do so.

Then you will always get cases where the scheduler does not do what the user
wants because the scheduler does not *know* what the user wants. You always
have to tell a computer what you want it to do, and the best it can do is
faithfully follow your request.

I think it's completely irrational to ask for a scheduler that automatically
gives more CPU time to CPU hogs.

> And if someone/distro *does* go to all the effort of managing how to get
> all the processes at the right nice levels, you have this big legacy
> problem where you're now stuck keeping all those nice values meaningful
> as you continue to develop the scheduler.  Its bad enough to make them
> do the work in the first place, but its worse if they need to make it a
> kernel version dependent function.

I agree. I'm not claiming to have the perfect solution. Let's not let the
perfect be the enemy of the good though.

DS

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Jeremy Fitzhardinge]

David Schwartz wrote:
>> There's a distinction between giving it more cpu and giving it higher
>> priority: the important part about having high priority is getting low
>> latency access to the cpu when its needed.
>>     
>
> I agree. Tasks that voluntarily relinquish their timeslices should get lower
> latency compared to other processes at the same static priority.
>
>   
>> This really seems like the wrong approach to me.  The implication here
>> and in other mails is that fairness is an inherently good thing which
>> should obviously take preference over any other property.
>>     
>
> Yes, that is the implication. The alternative to fairness is arbitrary
> unfairness. "Rational unfairness" is a form of fairness.
>
>   
>> The old unix-style dynamic priority scheme was designed to give
>> interactive processes high priorities, by using the observation that
>> "interactive" means "spends a lot of time blocked waiting for input".
>> That model of interactive is way too simple now, and the attempts to try
>> an find an equivalent heuristic have been flawed and lead to - in some
>> cases - wildly bad behaviours.  I'm guessing the emphasis on "fairness"
>> is in reaction to this, which is fair enough.
>>     
>
> I don't think it makes sense for the scheduler to look for some hint that
> the user would prefer a task to get more CPU and try to give it more. That's
> what 'nice' is for.
>
>   
>> But saying that the user needs to explicitly hold the schedulers hand
>> and nice everything to tell it how to schedule seems to be an abdication
>> of duty, an admission of failure.  We can't expect users to finesse all
>> their processes with nice, and it would be a bad user interface to ask
>> them to do so.
>>     
>
> Then you will always get cases where the scheduler does not do what the user
> wants because the scheduler does not *know* what the user wants. You always
> have to tell a computer what you want it to do, and the best it can do is
> faithfully follow your request.
>   

Hm, well.  The general preference has been for the kernel to do a
good-enough job on getting the common cases right without tuning, and
then only add knobs for the really tricky cases it can't do well.  But
the impression I'm getting here is that you often get sucky behaviours
without tuning.

> I think it's completely irrational to ask for a scheduler that automatically
> gives more CPU time to CPU hogs.
>   

Well, it doesn't have to.  It could give good low latency with short
timeslices to things which appear to be interactive.  If the interactive
program doesn't make good use of its low latency, then it will suck. 
But that's largely independent of how much overall CPU you give it.

> I agree. I'm not claiming to have the perfect solution. Let's not let the
> perfect be the enemy of the good though.
>   

For all its faults, the current scheduler mostly does a good job without
much tuning - I normally only use "nice" to run cpu-bound things without
jacking the cpu speed up.  Certainly in my normal interactive use of
compiz vs make -j4 on a dual-core generally gets pretty pretty good
results.  I plan on testing the new scheduler soon though.

    J

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Bill Huey]

On Tue, Mar 13, 2007 at 01:10:40PM -0700, Jeremy Fitzhardinge wrote:
> David Schwartz wrote:
> Hm, well.  The general preference has been for the kernel to do a
> good-enough job on getting the common cases right without tuning, and
> then only add knobs for the really tricky cases it can't do well.  But
> the impression I'm getting here is that you often get sucky behaviours
> without tuning.

Well, you get strict behaviors as expected for this scheduler. 

> > I think it's completely irrational to ask for a scheduler that automatically
> > gives more CPU time to CPU hogs.
> >   
> 
> Well, it doesn't have to.  It could give good low latency with short
> timeslices to things which appear to be interactive.  If the interactive
> program doesn't make good use of its low latency, then it will suck. 
> But that's largely independent of how much overall CPU you give it.

This is way beyond what SCHED_OTHER should do. It can't predict the universe.
Much of the interactivity estimator borders on magic. It just happens to
also "be a good fit" for hacky apps as well almost by accident.

> > I agree. I'm not claiming to have the perfect solution. Let's not let the
> > perfect be the enemy of the good though.
> 
> For all its faults, the current scheduler mostly does a good job without
> much tuning - I normally only use "nice" to run cpu-bound things without
> jacking the cpu speed up.  Certainly in my normal interactive use of
> compiz vs make -j4 on a dual-core generally gets pretty pretty good
> results.  I plan on testing the new scheduler soon though.

We can do MUCH better in the long run with something like Con's scheduler.
His approach shouldn't be dismissed because it's running into a relatively
few minor snags large the fault of scheduleing opaque applications. It's
precise enough that it can also be loosened up a bit with additional
control terms (previous email).

It might be good to think about that a bit to see if a schema like this can
be made more adaptable for the environment it serves. You'd then have both
precisely bounded control over CPU usage and enough flexibility for burstly
needs of certain apps.

bill

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Bill Huey]

On Tue, Mar 13, 2007 at 12:58:01PM -0700, David Schwartz wrote:
> > But saying that the user needs to explicitly hold the schedulers hand
> > and nice everything to tell it how to schedule seems to be an abdication
> > of duty, an admission of failure.  We can't expect users to finesse all
> > their processes with nice, and it would be a bad user interface to ask
> > them to do so.
> 
> Then you will always get cases where the scheduler does not do what the user
> wants because the scheduler does not *know* what the user wants. You always
> have to tell a computer what you want it to do, and the best it can do is
> faithfully follow your request.
> 
> I think it's completely irrational to ask for a scheduler that automatically
> gives more CPU time to CPU hogs.

SGI machines had an interactive term in their scheduler as well as a
traditional nice priority. It might be useful for Con to possibly consider
this as an extension for problematic (badly hacked) processes like X.

Nice as a control mechanism is rather coarse, yet overly strict because of
the sophistication of his scheduler. Having an additional term (control knob)
would be nice for a scheduler that is built upon (correct me if I'm wrong Con):

1) has rudimentary bandwidth control for a group of runnable processes
2) has a basic deadline mechanism

The "nice" term is only an indirect way of controlling his scheduler and
think and this kind of imprecise tweeking being done with various apps is an
indicator of how lacking it is as a control term in the scheduler. It would
be good to have some kind of coherent and direct control over the knobs that
are (1) and (2).

Schedulers like this have superior control over these properties and they
should be fully exploited with terms in additional to "nice".

Item (1) is subject to a static "weight" multiplication in relation to other
runnable tasks. It also might be useful to make a part of that term a bit
dynamic to get some kind of interactivity control back. It's a matter of
testing, tweeking, etc... and are not easy for apps that don't have a
direct thread context to control like a thread unaware X system.

> > And if someone/distro *does* go to all the effort of managing how to get
> > all the processes at the right nice levels, you have this big legacy
> > problem where you're now stuck keeping all those nice values meaningful
> > as you continue to develop the scheduler.  Its bad enough to make them
> > do the work in the first place, but its worse if they need to make it a
> > kernel version dependent function.
> 
> I agree. I'm not claiming to have the perfect solution. Let's not let the
> perfect be the enemy of the good though.

I hope this was useful.

bill

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Pavel Machek]

Hi!

> >> > Killing the known corner case starvation scenarios 
> >is wonderful, but
> >> > let's not just pretend that interactive tasks don't 
> >have any special
> >> > requirements.
> >>
> >> Now you're really making a stretch of things. Where 
> >on earth did I say that
> >> interactive tasks don't have special requirements? 
> >It's a fundamental feature
> >> of this scheduler that I go to great pains to get 
> >them as low latency as
> >> possible and their fair share of cpu despite having a 
> >completely fair cpu
> >> distribution.
> >
> >As soon as your cpu is fully utilized, fairness looses 
> >or interactivity
> >loses.  Pick one.
> 
> That's not true unless you refuse to prioritise your 
> tasks
> accordingly. Let's take this discussion in a different 
> direction. You
> already nice your lame processes. Why? You already have 
> the concept
> that you are prioritising things to normal or background 
> tasks. You
> say so yourself that lame is a background task. Stating 
> the bleedingly
> obvious, the unix way of prioritising things is via 
> nice. You already
> do that. So moving on from that...
> 
> Your test case you ask "how can I maximise cpu usage". 
> Well you know
> the answer already. You run two threads. I won't dispute 
> that.
> 
> The debate seems to be centered on whether two tasks 
> that are niced +5
> or to a higher value is background. In my opinion, nice 
> 5 is not
> background, but relatively less cpu. You already are 
> savvy enough to
> be using two threads and nicing them. All I ask you to 
> do when using
> RSDL is to change your expectations slightly and your 
> settings from
> nice 5 to nice 10 or 15 or even 19. Why is that so 
> offensive to you?
> nice 5 is 75% the cpu of nice 0. nice 10 is 50%, nice 15 
> is 25%, nice

Hmm, I'd certainly expect nice to be stronger. nice 5 should be 50% or
less of nice 0... You'll not even notice nice 2 if that is 90%...

And I guess it nicely solves problem in this thread, too...
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[David Lang]

On Mon, 12 Mar 2007, Mike Galbraith wrote:

> On Tue, 2007-03-13 at 07:38 +1100, Con Kolivas wrote:
>> On Tuesday 13 March 2007 07:11, Mike Galbraith wrote:
>>>
>>> Killing the known corner case starvation scenarios is wonderful, but
>>> let's not just pretend that interactive tasks don't have any special
>>> requirements.
>>
>> Now you're really making a stretch of things. Where on earth did I say that
>> interactive tasks don't have special requirements? It's a fundamental feature
>> of this scheduler that I go to great pains to get them as low latency as
>> possible and their fair share of cpu despite having a completely fair cpu
>> distribution.
>
> As soon as your cpu is fully utilized, fairness looses or interactivity
> loses.  Pick one.

correct.

the problem is that it's hard (if not impossible) to properly identify what is 
needed to make a system have good interactivity. in some cases it's a matter of 
low latency (wake up a process as quickly as you can when whatever it was 
waiting on is available), but in others it's a matter of allocating the _right_ 
process enough CPU (X needs enough CPU to do things)

where it's a matter of needing low-latency, it's possible to design a scheduler 
that will do things in a predictable enough way that you know the max latency 
you have to deal with (and the RSDL seems to do this)

the problem comes when this isn't enough. if you have several CPU hogs on a 
system, and they are all around the same priority level, how can the scheduler 
know which one needs the CPU the most for good interactivity?

in some cases you may be able to directly detect that your high-priority process 
is waiting for another one (tracing pipes and local sockets for example), but 
what if you are waiting for several of them? (think a multimedia desktop waiting 
for the sound card, CDRom, hard drive, and video all at once) which one needs 
the extra CPU the most?

Fairness is much easier to enforce (and much easier to understand)

the RSDL is concentrating on enforcing fairness, with bounded (and predictable) 
latencies.

if you are willing to tell the system what you consider more important (and how 
much more important you consider it), then it's much easier to figure out who to 
give the CPU to. Con is just asking you to do this (and you already do, by doing 
a nice -5. but it sounds like you want that to mean more then it currently does)

David Lang

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Lee Revell]

On 3/12/07, David Lang <david.lang@digitalinsight.com> wrote:
> the problem comes when this isn't enough. if you have several CPU hogs on a
> system, and they are all around the same priority level, how can the scheduler
> know which one needs the CPU the most for good interactivity?
>
> in some cases you may be able to directly detect that your high-priority process
> is waiting for another one (tracing pipes and local sockets for example), but
> what if you are waiting for several of them? (think a multimedia desktop waiting
> for the sound card, CDRom, hard drive, and video all at once) which one needs
> the extra CPU the most?

I'm not an expert in this area by any means but after reading this
thread the OSX solution of simply telling the kernel "I'm the GUI,
schedule me accordingly" looks increasingly attractive.  Why make the
kernel guess when we can just be explicit?

Does anyone know of a UNIX-like system that has managed to solve this
problem without hooking the GUI into the scheduler?

Lee

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[David Lang]

On Mon, 12 Mar 2007, Lee Revell wrote:

> On 3/12/07, David Lang <david.lang@digitalinsight.com> wrote:
>> the problem comes when this isn't enough. if you have several CPU hogs on a
>> system, and they are all around the same priority level, how can the 
>> scheduler
>> know which one needs the CPU the most for good interactivity?
>> 
>> in some cases you may be able to directly detect that your high-priority 
>> process
>> is waiting for another one (tracing pipes and local sockets for example), 
>> but
>> what if you are waiting for several of them? (think a multimedia desktop 
>> waiting
>> for the sound card, CDRom, hard drive, and video all at once) which one 
>> needs
>> the extra CPU the most?
>
> I'm not an expert in this area by any means but after reading this
> thread the OSX solution of simply telling the kernel "I'm the GUI,
> schedule me accordingly" looks increasingly attractive.  Why make the
> kernel guess when we can just be explicit?

this can solve the specific problem (and since 'nice' is the natural way to tell 
the kernel this, it's not even a one-shot solution).

however Linus is right, the real underlying problem is where the user is 
waiting on a server. if this issue could be solved then a lot of things would 
benifit.

Con, as a quick hack (probably a bad idea as I'm not a scheduling expert), if a 
program blocks on another program (via a pipe or socket) could you easily give 
the rest of the first program's timeslice to the second one, without makeing it 
loose it's own?

I'm thinking that doing the dumb thing and just throwing a bit more CPU at the 
thing you are waiting for may work. (assuming that the server process actually 
does something useful with the extra CPU time it gets)

as far as latencies go, it would be like turning every process on the system 
into a cpu hog.

David Lang

> Does anyone know of a UNIX-like system that has managed to solve this
> problem without hooking the GUI into the scheduler?
>
> Lee
>

Re: [ck] Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[jos poortvliet]

[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]

Op Monday 12 March 2007, schreef Con Kolivas:
> > > If we fix 95% of the desktop and worsen 5% is that bad given how much
> > > else we've gained in the process?
> >
> > Killing the known corner case starvation scenarios is wonderful, but
> > let's not just pretend that interactive tasks don't have any special
> > requirements.
>
> Now you're really making a stretch of things. Where on earth did I say that
> interactive tasks don't have special requirements? It's a fundamental
> feature of this scheduler that I go to great pains to get them as low
> latency as possible and their fair share of cpu despite having a completely
> fair cpu distribution.

As far as I understand it, RSDL always gives an equal share of cpu, but 
interactive tasks can have lower latency, right? So you get in trouble with 
interactive tasks only when their share isn't enough to actually do what they 
have to do in that period, eg on a heavily (over?) loaded box. Staircase, 
like mainline which gave them MORE than their share, would support that 
(though this comes at a price).

So, if your box is overloaded to a great extend, X, which can use a lot of 
cpu, can get unresponsive - unless it's negatively niced. But most other apps 
aren't as demanding as X is, so they won't really suffer. Thus the problem is 
mostly X. And at least part of that problem is being solved - X wasting cpu 
cycles. Also, cpu's are getting stronger, and I think it's likely X's 
relative CPU usage goes down as well.

In the long term, RSDL seems like the best way to go. Nice X down, and you got 
most of the disadvantages. You still have the perfect fairness, no stalls and 
starvation ;-)

If RSDL can be improved to help X, great. But introducing again the problem 
which RSDL was supposed to solve would be pretty pointless. I think that's 
what grumpy Con is trying to say, and he's right at it.

grtz

Jos

-- 
Disclaimer:

Alles wat ik doe denk en zeg is gebaseerd op het wereldbeeld wat ik nu heb. 
Ik ben niet verantwoordelijk voor wijzigingen van de wereld, of het beeld wat 
ik daarvan heb, noch voor de daaruit voortvloeiende gedragingen van mezelf. 
Alles wat ik zeg is aardig bedoeld, tenzij expliciet vermeld.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ck] Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[michael chang]

On 3/12/07, Con Kolivas <kernel@kolivas.org> wrote:
> On Tuesday 13 March 2007 07:11, Mike Galbraith wrote:
> > On Tue, 2007-03-13 at 05:49 +1100, Con Kolivas wrote:
> > > On Tuesday 13 March 2007 01:34, Mike Galbraith wrote:
> > > > On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> > > > > Mike the cpu is being proportioned out perfectly according to
> > > > > fairness as I mentioned in the prior email, yet X is getting the
> > > > > lower latency scheduling. I'm not sure within the bounds of fairness
> > > > > what more would you have happen to your liking with this test case?
> > > >
> > > > It has been said that "perfection is the enemy of good".  The two
> > > > interactive tasks receiving 40% cpu while two niced background jobs
> > > > receive 60% may well be perfect, but it's damn sure not good.
> > >
> > > Again I think your test is not a valid testcase. Why use two threads for
> > > your encoding with one cpu? Is that what other dedicated desktop OSs
> > > would do?
> >
> > The testcase is perfectly valid.  My buddies box has two full cores, so
> > we used two encoders such that whatever bandwidth is not being actively
> > consumed by more important things gets translated into mp3 encoding.
> >
> > How would you go about ensuring that there won't be any cycles wasted?
> >
> > _My_ box has 1 core that if fully utilized translates to 1.2 cores.. or
> > whatever, depending on the phase of the moon.  But no matter, logical vs
> > physical cpu argument is pure hand-waving.  What really matters here is
> > the bottom line: your fair scheduler ignores the very real requirements
> > of interactivity.
>
> Definitely not. It does not give unfair cpu towards interactive tasks. That's
> a very different argument.

I think the issue here is that the scheduler is doing what Con expects
it to do, but not what Mike Galbraith here feels it should do. Maybe
Con and Mike here are using different definitions, as such, for
"interactivity", or at least have different ideas of how this is
supposed to be accomplished. Does that sound right?

I've begun using RSDL on my machines here, and so far there haven't
been any issues with it, in my opinion. From a feel standpoint, it's
not what I would call perfectly smooth, but it is better than the
other schedulers I've seen (and the one case where there are still
problems it is an issue of I/O contention, not CPU -- using RSDL has
made a surprisingly large impact regardless).

Perhaps, Mike Galbraith, do you feel that it should be possible to use
the CPU at 100% for some task and still maintain excellent
interactivity? (It has always seemed to me that if you wanted
interactivity, you had to have the CPU idle at least a couple percent
of the time. How much or how little that many percent had to be was
usually affected by how much preempting you put in the kernel, and
what CPU scheduler was in it at the time.)

Considering the concepts put out by projects such as BOINC and
SETI@Home, I wouldn't be thoroughly surprised by this ideology,
although I do question the particular way this test case is being run.

That said, I haven't run the test case in particular yet, although I
will see if I can get the time to do so soon. In any case, I
personally do have a few qualms about this test case being run on HT
virtual cores:

* I am curious about why splitting a task and running them on separate
HT virtual cores improves interactivity any. (If it was Amarok on one
virtual CPU and one lame on the other, I would get it. But I see two
lame processes here -- wouldn't they just be allocated one to each
virtual CPU, leaving Amarok out most of the time? How do you get
interactivity with that?) Does using HT really fill up the CPU better
than having the CPU announce itself as the single core it is? My
understanding is that throughput goes down somewhat even just by using
multiple threads with HT, compared to the single thread on the single
core, and why would you use more than one lame thread unless you seek
throughput?

* Where are the lame processes encoding to/from? For example, are the
results for both being sent to /dev/null? To a hard drive? etc. etc.
In a real-world test case, I would imagine a user running TWO lame
processes would be encoding from two sources to the same hard drive.
(Or, they might even be both encoding FROM that same hard drive. Or
both.) The need for the single HD to seek so much reduces throughput
on most of these cases in HT, IIRC, which may be a factor that would
probably defeat the point of this case for most users. Of course, my
point is negated if they have multiple drives for their use of lame,
and/or if they have sufficient memory and bandwidth to handle the
issue, or if encoding throughput isn't their aim.

The only reason I can think of that running two lame processes would
improve "interactivity" would be so that if one particular portion
gets stuck, then there's a chance the other thread will be working on
an easier portion, making it appear like more is being done.  This
occurs, for example, with POV-Ray and Blender, where some parts of the
image may require more time to render than others due to the variable
complexity of various portions of a 3D image. In this case, using HT
or multiple threads makes it more likely that at least one thread will
be working on an "easy" spot, which would increase the number of
pixels on screen in e.g. the middle of the render. However, the
overall render usually wouldn't speed up on HT. In fact, the whole
image may even take slightly longer due to the overhead of the
threading, although that overhead is trivial for most users when they
are using it. (And of course, the overhead would be negligible when
you had two or more actual cores, because the increase would be more
like 1.85x when you factored out the overhead. HT, by contrast, would
give you, maybe 0.97x. Or whatever.)

As for the realism of the scenario, maybe one might have a Linux
server that is broadcasting/encoding the same source for multiple bit
rates (e.g. Internet Radio) might run multiple lame instances... on a
single core with HT. Not the most common thing in the world, but there
are still quite a few of these guys out there. Enough to be of
concern, IMO.

Con has indicated somewhere recently he has an idea about improving
negative nice; among other things -- maybe RSDL isn't capable of
handling this test case yet, but it might very soon. Considering that
any process not run at the top nice level ends up with pockets of
smoothness followed by pauses of a determinable size, processes like
lame that handle bits and pieces as fast at they come but need to do
so at a steady rate may act peculiarly (not smoothly?) under RSDL.

One last thing I'm not sure about: Mike, are you upset about lame
interfering with Amarok, or lame in and of itself? Which process do
you feel is getting too much or too little CPU? Why?

> > > And let's not lose sight of things with this one testcase.
> > >
> > > RSDL fixes
> > > - every starvation case
> > > - all fairness isssues
> > > - is better 95% of the time on the desktop
> >
> > I don't know where you got that 95% number from.  For the most part, the
> > existing scheduler does well.  If it sucked 95% of the time, it would
> > have been shredded a long time ago.
>
> Check the number of feedback reports. I don't feel petty enough to count them
> personally to give you an accuracte percentage.

I think Con is saying here that Mike, you are one of two or so people
so far to have given a primarily negative feedback report on RSDL. (I
think akpm hit a snag on some PPC box with -mm a while back, IIRC, and
then there's you. I'm only on -ck, though, so there may be others I
haven't heard about. But these two pale in comparison to the
complements I've seen on-list.) Of course, it's still important that
we see WHY it doesn't work well for you, while everyone else is having
fewer (or no) issues.

> > > If we fix 95% of the desktop and worsen 5% is that bad given how much
> > > else we've gained in the process?
> >
> > Killing the known corner case starvation scenarios is wonderful, but
> > let's not just pretend that interactive tasks don't have any special
> > requirements.
>
> Now you're really making a stretch of things. Where on earth did I say that
> interactive tasks don't have special requirements? It's a fundamental feature
> of this scheduler that I go to great pains to get them as low latency as
> possible and their fair share of cpu despite having a completely fair cpu
> distribution.

This seems to me like he's saying that there has to be a mechanism
(outside of nice) that can be used to treat processes that "I" want to
be interactive all special-like. It feels like something that would
have been said in the design of what the scheduler was in -ck and is
currently in vanilla.

To me, that fundamentally clashes with the design behind RSDL. That
said, I could be wrong -- Con appears to have something that could be
very promising up his sleeve that could come out sooner or later. Once
he's written it, of course. In any case, RSDL seems very promising,
for the most part.

--
Michael Chang

Re: [ck] Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Thibaut VARENE]

On 3/12/07, michael chang <thenewme91@gmail.com> wrote:

> Considering the concepts put out by projects such as BOINC and
> SETI@Home, I wouldn't be thoroughly surprised by this ideology,
> although I do question the particular way this test case is being run.

If Con actually implements SCHED_IDLEPRIO in RSDL, life is good even
in that case.

> This seems to me like he's saying that there has to be a mechanism
> (outside of nice) that can be used to treat processes that "I" want to
> be interactive all special-like. It feels like something that would
> have been said in the design of what the scheduler was in -ck and is
> currently in vanilla.

Exactly. Driving us again toward the fact that different workloads
might benefit from different schedulers (eg: RSDL is cool for server
loads, previous staircase did an excellent job on desktop, etc) and
thus that having a choice of schedulers might be something that would
satisfy (some) people...

> To me, that fundamentally clashes with the design behind RSDL. That
> said, I could be wrong -- Con appears to have something that could be
> very promising up his sleeve that could come out sooner or later. Once
> he's written it, of course. In any case, RSDL seems very promising,
> for the most part.

It certainly is. "Negative" feedback can be a good thing too, as it
helps improving it anyway. It's nonetheless true that it's practically
impossible to satisfy 100% of use case with a single design, so
choices will have to be made.

HTH

T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/

Re: [ck] Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Mon, 2007-03-12 at 17:38 -0400, michael chang wrote:

> Perhaps, Mike Galbraith, do you feel that it should be possible to use
> the CPU at 100% for some task and still maintain excellent
> interactivity?

Within reason, yes.  Defining "reason" is difficult.  As we speak, this
is possible to a much greater degree than with RSDL.  Before anybody
pipes in, yes, I'm very much aware of the down side of the interactivity
estimator, I've waged bloody battles with it, and have the t-shirt :)

> That said, I haven't run the test case in particular yet, although I
> will see if I can get the time to do so soon. In any case, I
> personally do have a few qualms about this test case being run on HT
> virtual cores:

Virtual or physical cores has nothing to do with the interactivity
regression I noticed.  Two nice 0 tasks which combined used 50% of my
box can no longer share that box with two nice 5 tasks and receive the
50% they need to perform.  That's it. From there, we wandered off into a
discussion on the relative merit and pitfalls of fairness.

	-Mike

Re: [ck] Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On Tuesday 13 March 2007 17:08, Mike Galbraith wrote:
> Virtual or physical cores has nothing to do with the interactivity
> regression I noticed.  Two nice 0 tasks which combined used 50% of my
> box can no longer share that box with two nice 5 tasks and receive the
> 50% they need to perform.  That's it. From there, we wandered off into a
> discussion on the relative merit and pitfalls of fairness.

And again, with X in its current implementation it is NOT like two nice 0 
tasks at all; it is like one nice 0 task. This is being fixed in the X design 
as we speak.

> 	-Mike

-- 
-ck

Re: [ck] Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Tue, 2007-03-13 at 17:16 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 17:08, Mike Galbraith wrote:
> > Virtual or physical cores has nothing to do with the interactivity
> > regression I noticed.  Two nice 0 tasks which combined used 50% of my
> > box can no longer share that box with two nice 5 tasks and receive the
> > 50% they need to perform.  That's it. From there, we wandered off into a
> > discussion on the relative merit and pitfalls of fairness.
> 
> And again, with X in its current implementation it is NOT like two nice 0 
> tasks at all; it is like one nice 0 task. This is being fixed in the X design 
> as we speak.

Shrug.  I don't live then, I live now.  I have expressed my concerns,
and will now switch from talk back to listen mode.

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Peter Zijlstra]

On Mon, 2007-03-12 at 21:11 +0100, Mike Galbraith wrote:

> How would you go about ensuring that there won't be any cycles wasted?

SCHED_IDLE or otherwise nice 19
 
> Killing the known corner case starvation scenarios is wonderful, but
> let's not just pretend that interactive tasks don't have any special
> requirements.

Interaction wants low latency, getting that is traditionally expressed
in priorities - the highest prio gets the least latency (all RTOSs work
like that).

There is nothing that warrants giving them more CPU time IMHO; if you
think they deserve more, express that using priorities.

Priorities are a well understood concept and they work; heuristics can
(and Murphy tells us they will) go wrong.

Getting the server/client thing working can be done without heuristics
using class based scheduling.

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Serge Belyshev]

Mike Galbraith <efault@gmx.de> writes:

[snip]
>> And let's not lose sight of things with this one testcase.
>> 
>> RSDL fixes
>> - every starvation case
>> - all fairness isssues
>> - is better 95% of the time on the desktop
>
> I don't know where you got that 95% number from.  For the most part, the
> existing scheduler does well.  If it sucked 95% of the time, it would
> have been shredded a long time ago.
>

I tell you.

http://article.gmane.org/gmane.linux.kernel/500027
http://article.gmane.org/gmane.linux.kernel/502996
http://article.gmane.org/gmane.linux.kernel/500119
http://article.gmane.org/gmane.linux.kernel/500784
http://article.gmane.org/gmane.linux.kernel/500768
http://article.gmane.org/gmane.linux.kernel/502255
http://article.gmane.org/gmane.linux.kernel/502282
http://article.gmane.org/gmane.linux.kernel/503650
http://article.gmane.org/gmane.linux.kernel/503695
http://article.gmane.org/gmane.linux.kernel.ck/6512
http://article.gmane.org/gmane.linux.kernel.ck/6539
http://article.gmane.org/gmane.linux.kernel.ck/6565


Also, count my email too.
I'm using RSDL since day one on my laptop and my router/compute server
and I wont come back to mainline, needless to say why.

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Tue, 2007-03-13 at 00:05 +0300, Serge Belyshev wrote:
> Mike Galbraith <efault@gmx.de> writes:
> 
> [snip]
> >> And let's not lose sight of things with this one testcase.
> >> 
> >> RSDL fixes
> >> - every starvation case
> >> - all fairness isssues
> >> - is better 95% of the time on the desktop
> >
> > I don't know where you got that 95% number from.  For the most part, the
> > existing scheduler does well.  If it sucked 95% of the time, it would
> > have been shredded a long time ago.
> >
> 
> I tell you.
> 
> http://article.gmane.org/gmane.linux.kernel/500027
> http://article.gmane.org/gmane.linux.kernel/502996
> http://article.gmane.org/gmane.linux.kernel/500119
> http://article.gmane.org/gmane.linux.kernel/500784
> http://article.gmane.org/gmane.linux.kernel/500768
> http://article.gmane.org/gmane.linux.kernel/502255
> http://article.gmane.org/gmane.linux.kernel/502282
> http://article.gmane.org/gmane.linux.kernel/503650
> http://article.gmane.org/gmane.linux.kernel/503695
> http://article.gmane.org/gmane.linux.kernel.ck/6512
> http://article.gmane.org/gmane.linux.kernel.ck/6539
> http://article.gmane.org/gmane.linux.kernel.ck/6565

Thanks, but I've already read them.  They are part of the reason I
decided to spend some time testing.

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Mon, 2007-03-12 at 12:08 +0100, Ingo Molnar wrote:
> * Mike Galbraith <efault@gmx.de> wrote:
> 
> > The test scenario was one any desktop user might do with every 
> > expectation responsiveness of the interactive application remain 
> > intact. I understand the concepts here Con, and I'm not knocking your 
> > scheduler. I find it to be a step forward on the one hand, but a step 
> > backward on the other.
> 
> ok, then that step backward needs to be fixed.

btw, this scenario wasn't invented by me, it came from the _every single
day_ usage of my best friend since his conversion to linux (he's in love
now;) a month ago.  After I un-crippled all of the multimedia apps that
came with our distribution, this is the thing he has been doing most.

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Xavier Bestel]

On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > Hmm.  So... anything that's client/server is going to suffer horribly
> > unless niced tasks are niced all the way down to 19?
> 
> Fortunately most client server models dont usually have mutually exclusive cpu 
> use like this X case. There are many things about X that are still a little 
> (/me tries to think of a relatively neutral term)... wanting. :(

I'd say the problem is less with X than with Xlib, which is heavily
round-trip-based. Fortunately XCB (its successor) seeks to be more
asynchronous.

	Xav

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On Monday 12 March 2007 20:38, Xavier Bestel wrote:
> On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> > On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > > Hmm.  So... anything that's client/server is going to suffer horribly
> > > unless niced tasks are niced all the way down to 19?
> >
> > Fortunately most client server models dont usually have mutually
> > exclusive cpu use like this X case. There are many things about X that
> > are still a little (/me tries to think of a relatively neutral term)...
> > wanting. :(
>
> I'd say the problem is less with X than with Xlib, which is heavily
> round-trip-based. Fortunately XCB (its successor) seeks to be more
> asynchronous.

Yes I recall a talk by Keith Packard on Xorg development and how a heck of a 
lot of time spent spinning by X (?Xlib) for no damn good reason was the 
number one thing that made X suck and basically it was silly to try and fix 
that at the cpu scheduler level since it needed to be corrected in X, and was 
being actively addressed. So we should stop trying to write cpu schedulers 
for X.

> 	Xav

-- 
-ck

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Kasper Sandberg]

On Mon, 2007-03-12 at 21:34 +1100, Con Kolivas wrote:
> On Monday 12 March 2007 20:38, Xavier Bestel wrote:
> > On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> > > On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > > > Hmm.  So... anything that's client/server is going to suffer horribly
> > > > unless niced tasks are niced all the way down to 19?
> > >
> > > Fortunately most client server models dont usually have mutually
> > > exclusive cpu use like this X case. There are many things about X that
> > > are still a little (/me tries to think of a relatively neutral term)...
> > > wanting. :(
> >
> > I'd say the problem is less with X than with Xlib, which is heavily
> > round-trip-based. Fortunately XCB (its successor) seeks to be more
> > asynchronous.
> 
> Yes I recall a talk by Keith Packard on Xorg development and how a heck of a 
> lot of time spent spinning by X (?Xlib) for no damn good reason was the 
> number one thing that made X suck and basically it was silly to try and fix 
> that at the cpu scheduler level since it needed to be corrected in X, and was 
> being actively addressed. So we should stop trying to write cpu schedulers 
> for X.
Excuse me for barging in. But.

with latest xorg, xlib will be using xcb internally, which afaik should
help matters a little, but furthermore, with the arrival of xcb, stuff
are bound to change somewhat fast, and with abit more incentive(as in,
real benefit on latest kernels), they are bound to change even faster.

and if people upgrading to newest X(using xlib w/xcb) and applications
being updated can help stuff out in the kernel, i'd say its best to push
for that.
> 
> > 	Xav
> 

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 258 bytes --]

On Mon, 12 Mar 2007 17:38:38 BST, Kasper Sandberg said:
> with latest xorg, xlib will be using xcb internally,

Out of curiosity, when is this "latest" Xorg going to escape to distros,
and is it far enough along that beta testers can gather usable numbers?


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Gabriel C]

Valdis.Kletnieks@vt.edu wrote:
> On Mon, 12 Mar 2007 17:38:38 BST, Kasper Sandberg said:
>   
>> with latest xorg, xlib will be using xcb internally,
>>     
>
> Out of curiosity, when is this "latest" Xorg going to escape to distros,
>   

Already is .. Xorg 7.2+ libx11 build with xcb enabled..


> and is it far enough along that beta testers can gather usable numbers?
>
>   

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Xavier Bestel]

On Wed, 2007-03-14 at 04:25 +0100, Gabriel C wrote:
> Valdis.Kletnieks@vt.edu wrote:
> > On Mon, 12 Mar 2007 17:38:38 BST, Kasper Sandberg said:
> >   
> >> with latest xorg, xlib will be using xcb internally,
> >>     
> >
> > Out of curiosity, when is this "latest" Xorg going to escape to distros,
> >   
> 
> Already is .. Xorg 7.2+ libx11 build with xcb enabled..

I think the true improvement will come when toolkits (GTK+ & Qt) are
ported to xcb.

	Xav

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Mon, 2007-03-12 at 18:48 +1100, Con Kolivas wrote:
> 
> Just a couple of questions;
> 
> The X/Gforce case; do they alternate cpu between them? By that I mean when 
> they're the only thing running does the cpu load summate to 1 or does it 
> summate to 2?

They're each on their own cpu (sibling).  Oh, you mean does one wake the
other?  If so, yeah, I believe so.  I instrumented wakeups a (long)
while back, looking into keeping heavy cpu visualizations smooth, and
iirc, X was waking it.

> Gforce presumably is a 3d visualisation? Do you use one of the graphics card 
> drivers listed that uses yield?

No, GL/DRI here.  I'm using a Radeon X850Pro (R480), and for GL/DRI I'd
have to load the proprietary driver.

	-Mike

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Gene Heskett]

On Sunday 11 March 2007, Mike Galbraith wrote:
>Hi Con,
>
>On Sun, 2007-03-11 at 14:57 +1100, Con Kolivas wrote:
>> What follows this email is a patch series for the latest version of
>> the RSDL cpu scheduler (ie v0.29). I have addressed all bugs that I am
>> able to reproduce in this version so if some people would be kind
>> enough to test if there are any hidden bugs or oops lurking, it would
>> be nice to know in anticipation of putting this back in -mm. Thanks.
>>
>> Full patch for 2.6.21-rc3-mm2:
>> http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0
>>.29.patch
>
>I'm seeing a cpu distribution problem running this on my P4 box.
>
>Scenario:
>listening to music collection (mp3) via Amarok.  Enable Amarok
>visualization gforce, and size such that X and gforce each use ~50% cpu.
>Start rip/encode of new CD with grip/lame encoder.  Lame is set to use
>both cpus, at nice 5.  Once the encoders start, they receive
>considerable more cpu than nice 0 X/Gforce, taking ~120% and leaving the
>remaining 80% for X/Gforce and Amarok (when it updates it's ~12k entry
>database) to squabble over.
>
>With 2.6.21-rc3,  X/Gforce maintain their ~50% cpu (remain smooth), and
>the encoders (100%cpu bound) get whats left when Amarok isn't eating it.
>
>I plunked the above patch into plain 2.6.21-rc3 and retested to
>eliminate other mm tree differences, and it's repeatable.  The nice 5
>cpu hogs always receive considerably more that the nice 0 sleepers.
>
>	-Mike

Just to comment, I've been running one of the patches between 20-ck1 and 
this latest one, which is building as I type, but I also run gkrellm 
here, version 2.2.9.

Since I have been running this middle of this series patch, something is 
killing gkrellm about once a day, and there is nothing in the logs to 
indicate a problem.  I see a blink out of the corner of my eye, and its 
gone.  And it always starts right back up from a kmenu click.

No idea if anyone else is experiencing this or not.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
You scratch my tape, and I'll scratch yours.

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Radoslaw Szkodzinski]

On 3/11/07, Gene Heskett <gene.heskett@gmail.com> wrote:
> On Sunday 11 March 2007, Mike Galbraith wrote:
>
> Just to comment, I've been running one of the patches between 20-ck1 and
> this latest one, which is building as I type, but I also run gkrellm
> here, version 2.2.9.
>
> Since I have been running this middle of this series patch, something is
> killing gkrellm about once a day, and there is nothing in the logs to
> indicate a problem.  I see a blink out of the corner of my eye, and its
> gone.  And it always starts right back up from a kmenu click.
>
> No idea if anyone else is experiencing this or not.
>
> --
> Cheers, Gene

I've had such an issue with 0.20 or something. Sometimes, the
xfce4-panel would disappear (die) when I displayed its menu.
Very rare issue.

Doesn't happen with 0.28 anyway. :-) Which looks really good, though
I'll update to 0.30.

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Gene Heskett]

On Monday 12 March 2007, Radoslaw Szkodzinski wrote:
>On 3/11/07, Gene Heskett <gene.heskett@gmail.com> wrote:
>> On Sunday 11 March 2007, Mike Galbraith wrote:
>>
>> Just to comment, I've been running one of the patches between 20-ck1
>> and this latest one, which is building as I type, but I also run
>> gkrellm here, version 2.2.9.
>>
>> Since I have been running this middle of this series patch, something
>> is killing gkrellm about once a day, and there is nothing in the logs
>> to indicate a problem.  I see a blink out of the corner of my eye, and
>> its gone.  And it always starts right back up from a kmenu click.
>>
>> No idea if anyone else is experiencing this or not.
>>
>> --
>> Cheers, Gene
>
>I've had such an issue with 0.20 or something. Sometimes, the
>xfce4-panel would disappear (die) when I displayed its menu.
>Very rare issue.
>
>Doesn't happen with 0.28 anyway. :-) Which looks really good, though
>I'll update to 0.30.

And I didn't see it for the few hours I was booted to 21-rc3-rsdl-0.29, 
but tar sure went berzackers.

To Con, I knew 2.6.20 worked with your earlier patches, so rather than 
revert all the way, I just rebooted to 2.6.20.2-rdsl-0.30 and I'm going 
to fire off another backup.  I suspect it will work, but will advise the 
next time I wake up.



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The hardest thing is to disguise your feelings when you put a lot of
relatives on the train for home.

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Gene Heskett]

On Monday 12 March 2007, Gene Heskett wrote:
>On Monday 12 March 2007, Radoslaw Szkodzinski wrote:
>>On 3/11/07, Gene Heskett <gene.heskett@gmail.com> wrote:
>>> On Sunday 11 March 2007, Mike Galbraith wrote:
>>>
>>> Just to comment, I've been running one of the patches between 20-ck1
>>> and this latest one, which is building as I type, but I also run
>>> gkrellm here, version 2.2.9.
>>>
>>> Since I have been running this middle of this series patch, something
>>> is killing gkrellm about once a day, and there is nothing in the logs
>>> to indicate a problem.  I see a blink out of the corner of my eye,
>>> and its gone.  And it always starts right back up from a kmenu click.
>>>
>>> No idea if anyone else is experiencing this or not.
>>>
>>> --
>>> Cheers, Gene
>>
>>I've had such an issue with 0.20 or something. Sometimes, the
>>xfce4-panel would disappear (die) when I displayed its menu.
>>Very rare issue.
>>
>>Doesn't happen with 0.28 anyway. :-) Which looks really good, though
>>I'll update to 0.30.
>
>And I didn't see it for the few hours I was booted to 21-rc3-rsdl-0.29,
>but tar sure went berzackers.
>
>To Con, I knew 2.6.20 worked with your earlier patches, so rather than
>revert all the way, I just rebooted to 2.6.20.2-rdsl-0.30 and I'm going
>to fire off another backup.  I suspect it will work, but will advise the
>next time I wake up.

After posting the above, I thought maybe I'd hit a target in the middle 
and build a 2.6.20.2, with your -0.30 patch, but...

I'm going to have to build a 2.6.20.2, because with the rdsl-0.30 patch, 
its going to do a level 2 on my /usr/movies directory, which hasn't been 
touched in 90 days and has about 8.1GB in it according to du, and its 
going to do nearly all of it.  It shouldn't be anything but a directory 
listing file. But this is what amstatus is reporting:
coyote:/usr/movies            2     7271m dumping      793m ( 10.91%) 
(7:26:00)

And its also reporting far more data than exists it seems. As is du, 
for /var, which might have 2 gigs, its claiming 3.7!

Honest folks, I'm not smoking anything, I quit 18 years ago.  Back to bed 
while this one bombs out too.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Operative: "I'm a monster.  What I do is evil, I've no illusions about 
that.  
But it must be done."
				--"Serenity"

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Con Kolivas]

On 12/03/07, Gene Heskett <gene.heskett@gmail.com> wrote:
> On Monday 12 March 2007, Gene Heskett wrote:
> >To Con, I knew 2.6.20 worked with your earlier patches, so rather than
> >revert all the way, I just rebooted to 2.6.20.2-rdsl-0.30 and I'm going
> >to fire off another backup.  I suspect it will work, but will advise the
> >next time I wake up.
>
> After posting the above, I thought maybe I'd hit a target in the middle
> and build a 2.6.20.2, with your -0.30 patch, but...
>
> I'm going to have to build a 2.6.20.2, because with the rdsl-0.30 patch,
> its going to do a level 2 on my /usr/movies directory, which hasn't been
> touched in 90 days and has about 8.1GB in it according to du, and its
> going to do nearly all of it.  It shouldn't be anything but a directory
> listing file. But this is what amstatus is reporting:
> coyote:/usr/movies            2     7271m dumping      793m ( 10.91%)
> (7:26:00)
>
> And its also reporting far more data than exists it seems. As is du,
> for /var, which might have 2 gigs, its claiming 3.7!
>
> Honest folks, I'm not smoking anything, I quit 18 years ago.  Back to bed
> while this one bombs out too.
>
> --
> Cheers, Gene

Gene your last good kernel you said was 2.6.20 based. I don't see a
good reason even to use 2.6.20.2 as a base given that information.

--
-ck

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Gene Heskett]

On Monday 12 March 2007, Con Kolivas wrote:
>On 12/03/07, Gene Heskett <gene.heskett@gmail.com> wrote:
>> On Monday 12 March 2007, Gene Heskett wrote:
>> >To Con, I knew 2.6.20 worked with your earlier patches, so rather
>> > than revert all the way, I just rebooted to 2.6.20.2-rdsl-0.30 and
>> > I'm going to fire off another backup.  I suspect it will work, but
>> > will advise the next time I wake up.
>>
>> After posting the above, I thought maybe I'd hit a target in the
>> middle and build a 2.6.20.2, with your -0.30 patch, but...
>>
>> I'm going to have to build a 2.6.20.2, because with the rdsl-0.30
>> patch, its going to do a level 2 on my /usr/movies directory, which
>> hasn't been touched in 90 days and has about 8.1GB in it according to
>> du, and its going to do nearly all of it.  It shouldn't be anything
>> but a directory listing file. But this is what amstatus is reporting:
>> coyote:/usr/movies            2     7271m dumping      793m ( 10.91%)
>> (7:26:00)
>>
>> And its also reporting far more data than exists it seems. As is du,
>> for /var, which might have 2 gigs, its claiming 3.7!
>>
>> Honest folks, I'm not smoking anything, I quit 18 years ago.  Back to
>> bed while this one bombs out too.
>>
>> --
>> Cheers, Gene
>
>Gene your last good kernel you said was 2.6.20 based. I don't see a
>good reason even to use 2.6.20.2 as a base given that information.
>
I have 2.6.20.1 building now.  I know that 2.6.20-ck1 worked well, so now 
I walking fwd from 2.6.20, trying to bisect it.  .1 wasn't much of a 
patch, but who knows at this point, I'm not 'the shadow' in a 65 year old 
radio show.  And it looks like that build is done, so here goes the next 
test.

The worst thing about this is that amanda's database is being hosed 
everytime this happens, and it's been 3 runs in a row, in a dumpcycle of 
5, where this has occurred.  I can do one more bad run by pre-clearing 
the vtape +1 that's it is going to use each time because the partition 
being used for vtapes is sitting at about 93% utilization now.  Normal 
life, its about 84%, it is a 175GB partition.  That also is stirring 
around in the old girls database when I kill stuff she thinks is there, 
but its also about 3 dumpcycles back and pretty much out of the picture 
so she will recover in a couple of dumpcycles once I find this, if indeed 
I do.

You've cooked up patches for all this, so it 2.6.20.1 works ok, then I try 
your patch on that one.  I tried 2.6.21-rc1, and it bombed too, but I 
just figured that was an -rc1, and we're expected to lose a pint of blood 
at most any -rc1 aren't we?, so I didn't give it any great thought and 
reverted till -rc2 came out.  But I ramble & times-a-wasting.
>--
>-ck

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Research is to see what everybody else has seen, and think what nobody
else has thought.

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Gene Heskett]

On Monday 12 March 2007, Gene Heskett wrote:
>On Monday 12 March 2007, Con Kolivas wrote:
>>On 12/03/07, Gene Heskett <gene.heskett@gmail.com> wrote:
>>> On Monday 12 March 2007, Gene Heskett wrote:
>>> >To Con, I knew 2.6.20 worked with your earlier patches, so rather
>>> > than revert all the way, I just rebooted to 2.6.20.2-rdsl-0.30 and
>>> > I'm going to fire off another backup.  I suspect it will work, but
>>> > will advise the next time I wake up.
>>>
>>> After posting the above, I thought maybe I'd hit a target in the
>>> middle and build a 2.6.20.2, with your -0.30 patch, but...
>>>
>>> I'm going to have to build a 2.6.20.2, because with the rdsl-0.30
>>> patch, its going to do a level 2 on my /usr/movies directory, which
>>> hasn't been touched in 90 days and has about 8.1GB in it according to
>>> du, and its going to do nearly all of it.  It shouldn't be anything
>>> but a directory listing file. But this is what amstatus is reporting:
>>> coyote:/usr/movies            2     7271m dumping      793m ( 10.91%)
>>> (7:26:00)
>>>
>>> And its also reporting far more data than exists it seems. As is du,
>>> for /var, which might have 2 gigs, its claiming 3.7!
>>>
>>> Honest folks, I'm not smoking anything, I quit 18 years ago.  Back to
>>> bed while this one bombs out too.
>>>
>>> --
>>> Cheers, Gene
>>
>>Gene your last good kernel you said was 2.6.20 based. I don't see a
>>good reason even to use 2.6.20.2 as a base given that information.
>
>I have 2.6.20.1 building now.  I know that 2.6.20-ck1 worked well, so
> now I walking fwd from 2.6.20, trying to bisect it.  .1 wasn't much of
> a patch, but who knows at this point, I'm not 'the shadow' in a 65 year
> old radio show.  And it looks like that build is done, so here goes the
> next test.
>
>The worst thing about this is that amanda's database is being hosed
>everytime this happens, and it's been 3 runs in a row, in a dumpcycle of
>5, where this has occurred.  I can do one more bad run by pre-clearing
>the vtape +1 that's it is going to use each time because the partition
>being used for vtapes is sitting at about 93% utilization now.  Normal
>life, its about 84%, it is a 175GB partition.  That also is stirring
>around in the old girls database when I kill stuff she thinks is there,
>but its also about 3 dumpcycles back and pretty much out of the picture
>so she will recover in a couple of dumpcycles once I find this, if
> indeed I do.
>
>You've cooked up patches for all this, so it 2.6.20.1 works ok, then I
> try your patch on that one.  I tried 2.6.21-rc1, and it bombed too, but
> I just figured that was an -rc1, and we're expected to lose a pint of
> blood at most any -rc1 aren't we?, so I didn't give it any great
> thought and reverted till -rc2 came out.  But I ramble &
> times-a-wasting.
>
For those following this thread, testing is halted momentarily due to a 
bug in my amanda wrapper scripts discovered when I told it to do a flush 
so the next run had a clean slate.  Alan Pearson and I are exchanging 
emails on that.  The script problem however is not connected to this, its 
just that the wrapper needs to be right under all conditions and it 
wasn't.  A few hours lag here.

Does anybody on the Cc: list need off it?

>>--
>>-ck



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"I am ecstatic that some moron re-invented a 1995 windows fuckup."
        -- Alan Cox

Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Al Boldi]

Xavier Bestel wrote:
> Le mardi 13 mars 2007 à 05:49 +1100, Con Kolivas a écrit :
> > Again I think your test is not a valid testcase. Why use two threads for
> > your encoding with one cpu? Is that what other dedicated desktop OSs
> > would do?
>
> as your scheduler
> is "strictly fair", won't that enable trivial DoS by just letting an
> user fork a multitude of CPU-intensive processes ?

I don't think we have to worry about DoS with this scheduler.
Note the load average; it happily wraps.

top - 22:34:02 up 8 min,  0 users,  load average: 615.32, 746.30, 929.15
Tasks: 3379 total, 3336 running,  43 sleeping,   0 stopped,   0 zombie
Cpu(s):   8.8% user,  21.1% system,  10.0% nice,  56.5% idle,   3.6% IO-wait
Mem:    499480k total,   414640k used,    84840k free,     1956k buffers
Swap:  1020088k total,        0k used,  1020088k free,     8296k cached

  PID  PR  NI  VIRT  RES  SHR SWAP nFLT nDRT WCHAN     S %CPU    TIME+  Command 
  614  39   0  3668 2712  720  956    5    0 rest_init R  1.9   0:09.70 top     
  845  23   0  3056 1780  932 1276    0    0 wait      S  0.0   0:01.96 sh      
    1  20   0  1440  504  444  936   14    0 rest_init S  0.0   0:00.76 init    
 4180  28   0  3664 2640  652 1024    0    0 rest_init R  3.5   0:00.40 top     
  863  39  19  1584  488  412 1096    0    0 rest_init R  0.0   0:00.30 ping    
  929  39  19  1584  488  412 1096    0    0 rest_init R  0.2   0:00.29 ping    
  871  39  19  1584  488  412 1096    0    0 rest_init R  0.2   0:00.28 ping    
  904  39  19  1584  488  412 1096    0    0 rest_init R  0.2   0:00.28 ping    
  946  39  19  1584  488  412 1096    0    0 rest_init R  0.2   0:00.28 ping    
  947  39  19  1584  488  412 1096    0    0 rest_init R  0.2   0:00.28 ping    
  972  39  19  1584  488  412 1096    0    0 rest_init R  0.0   0:00.28 ping    
  862  39  19  1584  488  412 1096    0    0 rest_init R  0.0   0:00.27 ping    
  881  39  19  1584  488  412 1096    0    0 rest_init R  0.0   0:00.27 ping    
  901  39  19  1584  488  412 1096    0    0 rest_init R  0.0   0:00.27 ping    
  915  39  19  1584  488  412 1096    0    0 rest_init R  0.0   0:00.27 ping    
  923  39  19  1584  488  412 1096    0    0 rest_init R  0.0   0:00.27 ping    
  926  39  19  1584  488  412 1096    0    0 rest_init R  0.0   0:00.27 ping    
  958  39  19  1584  488  412 1096    0    0 rest_init R  0.0   0:00.27 ping    
  967  39  19  1584  488  412 1096    0    0 rest_init R  0.0   0:00.27 ping    
  987  39  19  1584  488  412 1096    0    0 rest_init R  0.0   0:00.27 ping    
  994  39  19  1584  488  412 1096    0    0 rest_init R  0.2   0:00.27 ping    


Thanks!

--
Al