Nick's scheduler policy v15

Nick's scheduler policy v15

[Nick Piggin]

Hi,
http://www.kerneltrap.org/~npiggin/v15/

This was going to get high res timers, but instead fixed a bug that might
be causing a few people oopses. Also very small interactivity tweaks.

I'm starting to work on SMP and NUMA ideas now, so if any interactivity
things are bothering you, please tell me soon. I should be getting access
to a 32-way NUMA soon, so I'm sort of holding off chaning too much until
then.

Enjoy.

Re: Nick's scheduler policy v15

[Cliff White]

> Hi,
> http://www.kerneltrap.org/~npiggin/v15/
> 
> This was going to get high res timers, but instead fixed a bug that might
> be causing a few people oopses. Also very small interactivity tweaks.
> 
> I'm starting to work on SMP and NUMA ideas now, so if any interactivity
> things are bothering you, please tell me soon. I should be getting access
> to a 32-way NUMA soon, so I'm sort of holding off chaning too much until
> then.
> 
> Enjoy.
> 
Are these against 2.6.0-test5-mm1? We're not getting a clean apply over here. 
cliffw


sched-nopolicy:
---------------------
patching file kernel/fork.c
Hunk #1 FAILED at 912.
1 out of 1 hunk FAILED -- saving rejects to file kernel/fork.c.rej
patching file kernel/sched.c
Hunk #1 succeeded at 186 (offset 38 lines).
Hunk #3 succeeded at 241 (offset 37 lines).
Hunk #5 succeeded at 663 (offset 117 lines).
Hunk #6 succeeded at 847 (offset 7 lines).
Hunk #7 succeeded at 1013 (offset 117 lines).
Hunk #8 succeeded at 912 (offset 7 lines).
Hunk #9 succeeded at 1047 (offset 117 lines).
Hunk #10 succeeded at 986 (offset 7 lines).
Hunk #11 succeeded at 1114 (offset 117 lines).
Hunk #12 succeeded at 1029 (offset 7 lines).
Hunk #13 FAILED at 1056.
Hunk #14 succeeded at 1230 (offset 135 lines).
Hunk #15 succeeded at 1146 (offset 7 lines).
Hunk #16 FAILED at 1189.
Hunk #17 succeeded at 1343 (offset 136 lines).
Hunk #18 succeeded at 1233 (offset 7 lines).
Hunk #19 FAILED at 1249.
Hunk #20 succeeded at 2380 with fuzz 2 (offset -112 lines).
Hunk #21 FAILED at 2395.
Hunk #22 FAILED at 2445.
Hunk #23 succeeded at 3010 (offset 351 lines).
5 out of 23 hunks FAILED -- saving rejects to file kernel/sched.c.rej
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Nick's scheduler policy v15

[Mike Fedyk]

On Thu, Sep 11, 2003 at 04:29:24PM -0700, Cliff White wrote:
> > Hi,
> > http://www.kerneltrap.org/~npiggin/v15/
> > 
> > This was going to get high res timers, but instead fixed a bug that might
> > be causing a few people oopses. Also very small interactivity tweaks.
> > 
> > I'm starting to work on SMP and NUMA ideas now, so if any interactivity
> > things are bothering you, please tell me soon. I should be getting access
> > to a 32-way NUMA soon, so I'm sort of holding off chaning too much until
> > then.
> > 
> > Enjoy.
> > 
> Are these against 2.6.0-test5-mm1? We're not getting a clean apply over here. 

Try against test5... not -mm.

Re: Nick's scheduler policy v15

[Bill Davidsen]

On Thursday 11 September 2003 10:34 am, Nick Piggin wrote:
> Hi,
> http://www.kerneltrap.org/~npiggin/v15/
>
> This was going to get high res timers, but instead fixed a bug that might
> be causing a few people oopses. Also very small interactivity tweaks.
>
> I'm starting to work on SMP and NUMA ideas now, so if any interactivity
> things are bothering you, please tell me soon. I should be getting access
> to a 32-way NUMA soon, so I'm sort of holding off chaning too much until
> then.
>
> Enjoy.

The only odd behaviour I see with v15 (and also with v10) is that X 
occasionally terminates when I unlock the screen. Haven't run pure test[45] 
enough to say for sure that it doesn't happen there. Load was setiathome, 
kernel make -j3, calculate PI to 20k places. System was responsive and 
pleasant to use before I locked it, when I came back X died, system was still 
stable.

RH 7.3 base, 2.6.0-test5+nick15, PII-350, 96MB, KDE

Next week I'll run pure test5 for a day and see what happens. I'll also get 
some actual numbers on responsiveness (I think). After stability test I'll 
run test5-mm1 (or latest) and look for the X oddity. So far Nick-v15 seems to 
do a better job than test5-mm1, I don't have a sound card the system will use 
at the moment.

-- 
Bill Davidsen
  machine name and IP do not reflect reality, stealth in progress

Re: Nick's scheduler policy v15

[Cliff White]

> Hi,
> http://www.kerneltrap.org/~npiggin/v15/
> 

Here are results for several recent kernels for comparison.
the sched-rollup-nopolicy tests are still running. 
Performance of v15 suffers as number of CPU's increase.
At 8 cpu's, delta is noticeable vs stock -test5
cliffw

stp2 CPU machine
Database workload

STP id PLM# Kernel Name                    Workfile   MaxJPM  MaxU Change Host    Options
Newest Kernel - Baseline for % change
279766 2132 2.6.0-test5-sched-roll-v15-3   new_dbase  1317.56   22  0.00 stp2-000  profile=2 elevator=cfq
279764 2132 2.6.0-test5-sched-roll-v15-3   new_dbase  1333.37   22  1.20 stp2-002  profile=2 elevator=deadline
279762 2132 2.6.0-test5-sched-roll-v15-3   new_dbase  1311.99   22 -0.42 stp2-000  profile=2
279714 2124 2.6.0-test5-O1int20.1          new_dbase  1351.91   24  2.61 stp2-003  
279588 2112 2.6.0-test5-mm1-fix11.0        new_dbase  1316.95   22 -0.05 stp2-000  profile=2
279474 2110 linux-2.6.0-test5              new_dbase  1337.11   22  1.48 stp2-000  profile=2

Compute workload
STP id PLM# Kernel Name                    Workfile   MaxJPM  MaxU Change Host    Options
Newest Kernel - Baseline for % change
279765 2132 2.6.0-test5-sched-roll-v15-3   compute    1553.34   26  0.00 stp2-003  profile=2 elevator=deadline
279763 2132 2.6.0-test5-sched-roll-v15-3   compute    1488.25   26 -4.19 stp2-001  profile=2
279589 2112 2.6.0-test5-mm1-fix11.0        compute    1503.12   26 -3.23 stp2-001  profile=2
279475 2110 linux-2.6.0-test5              compute    1545.03   26 -0.53 stp2-002  profile=2


stp4 CPU machine
Database workload

STP id PLM# Kernel Name                    Workfile   MaxJPM  MaxU Change Host    Options
Newest Kernel - Baseline for % change
279772 2132 2.6.0-test5-sched-roll-v15-3   new_dbase  4986.82   60  0.00 stp4-000  profile=2 elevator=cfq
279770 2132 2.6.0-test5-sched-roll-v15-3   new_dbase  4935.10   60 -1.04 stp4-002  profile=2 elevator=deadline
279768 2132 2.6.0-test5-sched-roll-v15-3   new_dbase  4974.13   60 -0.25 stp4-000  profile=2
279606 2112 2.6.0-test5-mm1-fix11.0        new_dbase  5347.06   92  7.22 stp4-002  profile=2

Compute workload
STP id PLM# Kernel Name                    Workfile   MaxJPM  MaxU Change Host    Options
Newest Kernel - Baseline for % change
279769 2132 2.6.0-test5-sched-roll-v15-3   compute    5248.08   76  0.00 stp4-001  profile=2
279650 2117 2.6.0-test5-sched-rollup       compute    5134.75   88 -2.16 stp4-003  profile=2
279607 2112 2.6.0-test5-mm1-fix11.0        compute    5380.18   92  2.52 stp4-001  profile=2
279493 2110 linux-2.6.0-test5              compute    5175.28   88 -1.39 stp4-000  profile=2


stp8 CPU machine
Database workload

STP id PLM# Kernel Name                    Workfile   MaxJPM  MaxU Change Host    Options
Newest Kernel - Baseline for % change
279760 2132 2.6.0-test5-sched-roll-v15-3   new_dbase  7440.33   88  0.00 stp8-003  profile=2 elevator=cfq
279758 2132 2.6.0-test5-sched-roll-v15-3   new_dbase  7445.05   88  0.06 stp8-003  profile=2 elevator=deadline
279756 2132 2.6.0-test5-sched-roll-v15-3   new_dbase  7574.35   88  1.80 stp8-001  profile=2
279706 2124 2.6.0-test5-O1int20.1          new_dbase  8441.09  136 13.45 stp8-001  
279717 2120 2.6.0-test5.ck.O20.1int        new_dbase  8408.47  136 13.01 stp8-001  
279562 2112 2.6.0-test5-mm1-fix11.0        new_dbase  8478.10  136 13.95 stp8-001  profile=2 elevator=cfq
279560 2112 2.6.0-test5-mm1-fix11.0        new_dbase  8303.30  136 11.60 stp8-001  profile=2 elevator=deadline
279558 2112 2.6.0-test5-mm1-fix11.0        new_dbase  8401.98  136 12.92 stp8-001  profile=2
279448 2110 linux-2.6.0-test5              new_dbase  8812.21  144 18.44 stp8-000  profile=2 elevator=cfq
279446 2110 linux-2.6.0-test5              new_dbase  8950.07  144 20.29 stp8-002  profile=2 elevator=deadline
279444 2110 linux-2.6.0-test5              new_dbase  8785.24  144 18.08 stp8-002  profile=2

Compute workload

STP id PLM# Kernel Name                    Workfile   MaxJPM  MaxU Change Host    Options
Newest Kernel - Baseline for % change
279759 2132 2.6.0-test5-sched-roll-v15-3   compute    9111.87  120  0.00 stp8-001  profile=2 elevator=deadline
279757 2132 2.6.0-test5-sched-roll-v15-3   compute    9124.72  120  0.14 stp8-002  profile=2
279563 2112 2.6.0-test5-mm1-fix11.0        compute    9743.27  160  6.93 stp8-003  profile=2 elevator=cfq
279561 2112 2.6.0-test5-mm1-fix11.0        compute    9719.15  160  6.66 stp8-003  profile=2 elevator=deadline
279559 2112 2.6.0-test5-mm1-fix11.0        compute    9687.67  160  6.32 stp8-003  profile=2
279449 2110 linux-2.6.0-test5              compute    9666.02  160  6.08 stp8-003  profile=2 elevator=cfq
279445 2110 linux-2.6.0-test5              compute    9758.11  160  7.09 stp8-002  profile=2
> 

Re: Nick's scheduler policy v15

[Nick Piggin]

Cliff White wrote:

>>Hi,
>>http://www.kerneltrap.org/~npiggin/v15/
>>
>>
>
>Here are results for several recent kernels for comparison.
>the sched-rollup-nopolicy tests are still running. 
>Performance of v15 suffers as number of CPU's increase.
>At 8 cpu's, delta is noticeable vs stock -test5
>cliffw
>

OK, so it hasn't crashed? Do you have the profiles up?

Thanks,
Nick

Re: Nick's scheduler policy v15

[Nick Piggin]

Nick Piggin wrote:

>
>
> Cliff White wrote:
>
>>> Hi,
>>> http://www.kerneltrap.org/~npiggin/v15/
>>>
>>>
>>
>> Here are results for several recent kernels for comparison.
>> the sched-rollup-nopolicy tests are still running. Performance of v15 
>> suffers as number of CPU's increase.
>> At 8 cpu's, delta is noticeable vs stock -test5
>> cliffw
>>
>
> OK, so it hasn't crashed? Do you have the profiles up?


Nevermind, I found them. It looks like its balancing way too much. I've
a few ideas. I should be getting time on a NUMA box there at OSDL soon, 
so I won't bother you with untested stuff. Thanks again for doing
these.

Re: Nick's scheduler policy v15

[Cliff White]

> 
> 
> Nick Piggin wrote:
> 
> >
> >
> > Cliff White wrote:
> >
> >>> Hi,
> >>> http://www.kerneltrap.org/~npiggin/v15/
> >>>
> >>>
> >>
> >> Here are results for several recent kernels for comparison.
> >> the sched-rollup-nopolicy tests are still running. Performance of v15 
> >> suffers as number of CPU's increase.
> >> At 8 cpu's, delta is noticeable vs stock -test5
> >> cliffw
> >>
> >
> > OK, so it hasn't crashed? Do you have the profiles up?
> 
> 
> Nevermind, I found them. It looks like its balancing way too much. I've
> a few ideas. I should be getting time on a NUMA box there at OSDL soon, 
> so I won't bother you with untested stuff. Thanks again for doing
> these.
> 
It's not a bother, my robot slaves do all the work. 
http://www.osdl.org/plm-cgi/plm

:)
cliffw

> 

Nick's scheduler policy v15a

[Nick Piggin]

http://www.kerneltrap.org/~npiggin/v15a/

No changes apart from a sync with Linus' tree now that it includes Con's
stuff. It basically just reverts the patches that have gone in. I'm not
sure what the right way to do this would be, but it seems cleaner than to
wade through the remains of my patches after a brute force merge.

This still has known SMP regressions that I haven't got around to looking
at yet because there has been a bit of trouble with a big box I'm supposed
to get time on.

I am still not aware of any desktop / interactivity problems so tell me if
you find any.