2003-09-11 14:36:06

by Nick Piggin

[permalink] [raw]
Subject: Nick's scheduler policy v15

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.



2003-09-11 23:29:40

by Cliff White

[permalink] [raw]
Subject: Re: Nick's scheduler policy v15

> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>


2003-09-12 04:43:43

by Mike Fedyk

[permalink] [raw]
Subject: Re: Nick's scheduler policy v15

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.

2003-09-12 18:06:38

by Bill Davidsen

[permalink] [raw]
Subject: Re: Nick's scheduler policy v15

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

2003-09-12 18:42:58

by Cliff White

[permalink] [raw]
Subject: Re: Nick's scheduler policy v15

> 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
>

2003-09-13 02:06:46

by Nick Piggin

[permalink] [raw]
Subject: Re: Nick's scheduler policy v15



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

2003-09-13 11:17:29

by Nick Piggin

[permalink] [raw]
Subject: Re: Nick's scheduler policy v15



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.


2003-09-14 06:25:30

by Cliff White

[permalink] [raw]
Subject: Re: Nick's scheduler policy v15

>
>
> 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

>

2003-09-22 05:40:55

by Nick Piggin

[permalink] [raw]
Subject: Nick's scheduler policy v15a

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.