2009-09-27 19:47:09

by drago01

[permalink] [raw]
Subject: sched regression introduced by NO_NEW_FAIR_SLEEPERS

Hi,

Chuck has backported some scheduler patches from 2.6.32 to the fedora kernel.

I did the following test to test the new scheduler (cpu is a core i7
920 4 cores + HT).

run 8 "md5sum /dev/urandom" task and try to use the desktop (compiz).

The result was that moving windows or rotating the cube is very slow.
(same happens with pure metacity but is is worse in compiz).

Mounting debugfs and doing "echo NEW_FAIR_SLEEPERS > sched_features"
results into a useable desktop while the 8 md5sum tasks are running
(ie. the system behaves as if they where not running at all from an
interactivity pov).


P.S: please CC me when replying.


2009-09-27 19:50:09

by drago01

[permalink] [raw]
Subject: Re: sched regression introduced by NO_NEW_FAIR_SLEEPERS

On Sun, Sep 27, 2009 at 9:47 PM, drago01 <[email protected]> wrote:
> Hi,
>
> Chuck has backported some scheduler patches from 2.6.32 to the fedora kernel.
>
> I did the following test to test the new scheduler (cpu is a core i7
> 920 4 cores + HT).
>
> run 8 "md5sum /dev/urandom" task and try to use the desktop (compiz).
>
> The result was that moving windows or rotating the cube is very slow.
> (same happens with pure metacity but is is worse in compiz).
>
> Mounting debugfs and doing "echo NEW_FAIR_SLEEPERS > sched_features"
> results into a useable desktop while the 8 md5sum tasks are running
> (ie. the system behaves as if they where not running at all from an
> interactivity pov).
>
>
> P.S: please CC me when replying.
>

With "NEW_FAIR_SLEEPERS" I can even run 100(!) "md5sum" task without
any effect on interactivity. (still have not found a number of tasks
needed to make the system unresponsive as with 8 with
"NO_NEW_FAIR_SLEEPERS".

2009-09-27 19:52:03

by drago01

[permalink] [raw]
Subject: Re: sched regression introduced by NO_NEW_FAIR_SLEEPERS

On Sun, Sep 27, 2009 at 9:50 PM, drago01 <[email protected]> wrote:
> On Sun, Sep 27, 2009 at 9:47 PM, drago01 <[email protected]> wrote:
>> Hi,
>>
>> Chuck has backported some scheduler patches from 2.6.32 to the fedora kernel.
>>
>> I did the following test to test the new scheduler (cpu is a core i7
>> 920 4 cores + HT).
>>
>> run 8 "md5sum /dev/urandom" task and try to use the desktop (compiz).
>>
>> The result was that moving windows or rotating the cube is very slow.
>> (same happens with pure metacity but is is worse in compiz).
>>
>> Mounting debugfs and doing "echo NEW_FAIR_SLEEPERS > sched_features"
>> results into a useable desktop while the 8 md5sum tasks are running
>> (ie. the system behaves as if they where not running at all from an
>> interactivity pov).
>>
>>
>> P.S: please CC me when replying.
>>
>
> With "NEW_FAIR_SLEEPERS" I can even run 100(!) ?"md5sum" task without
> any effect on interactivity. (still have not found a number of tasks
> needed to make the system unresponsive as with 8 with
> "NO_NEW_FAIR_SLEEPERS".

Well ok I can expirence some delays when switching workspaces with 100
tasks but it is still better than 8 with "NO_NEW_FAIR_SLEEPERS"

2009-09-27 20:06:18

by drago01

[permalink] [raw]
Subject: Re: sched regression introduced by NO_NEW_FAIR_SLEEPERS

On Sun, Sep 27, 2009 at 9:47 PM, drago01 <[email protected]> wrote:
> Hi,
>
> Chuck has backported some scheduler patches from 2.6.32 to the fedora kernel.
>
> I did the following test to test the new scheduler (cpu is a core i7
> 920 4 cores + HT).
>
> run 8 "md5sum /dev/urandom" task and try to use the desktop (compiz).
>
> The result was that moving windows or rotating the cube is very slow.
> (same happens with pure metacity but is is worse in compiz).
>
> Mounting debugfs and doing "echo NEW_FAIR_SLEEPERS > sched_features"
> results into a useable desktop while the 8 md5sum tasks are running
> (ie. the system behaves as if they where not running at all from an
> interactivity pov).
>
>
> P.S: please CC me when replying.
>

OK, tried on a "vanilla 2.6.30.8 scheduler" I can reproduce this by
toggling NEW_FAIR_SLEEPERS on/off. (So it was not a side effect of
other scheduler patches)

2009-10-03 10:47:32

by Ingo Molnar

[permalink] [raw]
Subject: Re: sched regression introduced by NO_NEW_FAIR_SLEEPERS


* drago01 <[email protected]> wrote:

> On Sun, Sep 27, 2009 at 9:47 PM, drago01 <[email protected]> wrote:
> > Hi,
> >
> > Chuck has backported some scheduler patches from 2.6.32 to the fedora kernel.
> >
> > I did the following test to test the new scheduler (cpu is a core i7
> > 920 4 cores + HT).
> >
> > run 8 "md5sum /dev/urandom" task and try to use the desktop (compiz).
> >
> > The result was that moving windows or rotating the cube is very slow.
> > (same happens with pure metacity but is is worse in compiz).
> >
> > Mounting debugfs and doing "echo NEW_FAIR_SLEEPERS > sched_features"
> > results into a useable desktop while the 8 md5sum tasks are running
> > (ie. the system behaves as if they where not running at all from an
> > interactivity pov).
> >
> >
> > P.S: please CC me when replying.
> >
>
> With "NEW_FAIR_SLEEPERS" I can even run 100(!) "md5sum" task without
> any effect on interactivity. (still have not found a number of tasks
> needed to make the system unresponsive as with 8 with
> "NO_NEW_FAIR_SLEEPERS".

Can you try the latest -tip tree please:

http://people.redhat.com/mingo/tip.git/README

There we default to FAIR_SLEEPERS + GENTLE_FAIR_SLEEPERS - which should
give much of the new-fair-sleepers advantage.

There's also a new tool, 'perf sched', which you can install via:

cd tools/perf/
make -j install

And use like this to measure latencies in the system:

$ perf sched record sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.059 MB perf.data (~2563 samples) ]

$ perf sched latency

-----------------------------------------------------------------------------------------
Task | Runtime ms | Switches | Average delay ms | Maximum delay ms |
-----------------------------------------------------------------------------------------
events/12:47 | 0.007 ms | 1 | avg: 0.054 ms | max: 0.054 ms |
events/2:37 | 0.128 ms | 1 | avg: 0.016 ms | max: 0.016 ms |
at-spi-registry:3292 | 0.752 ms | 20 | avg: 0.015 ms | max: 0.023 ms |
Xorg:3161 | 0.519 ms | 20 | avg: 0.015 ms | max: 0.024 ms |
perf:19070 | 21.241 ms | 5 | avg: 0.012 ms | max: 0.019 ms |
events/1:36 | 0.009 ms | 1 | avg: 0.009 ms | max: 0.009 ms |
hald-addon-stor:2790 | 0.204 ms | 9 | avg: 0.009 ms | max: 0.011 ms |
scsi_eh_5:1072 | 0.200 ms | 12 | avg: 0.009 ms | max: 0.009 ms |
events/0:35 | 0.007 ms | 1 | avg: 0.008 ms | max: 0.008 ms |
ksoftirqd/12:28 | 0.088 ms | 5 | avg: 0.005 ms | max: 0.009 ms |
sleep:19071 | 0.668 ms | 3 | avg: 0.005 ms | max: 0.008 ms |
migration/13:29 | 0.000 ms | 1 | avg: 0.003 ms | max: 0.003 ms |
-----------------------------------------------------------------------------------------
TOTAL: | 23.824 ms | 79 |
---------------------------------------------------

Thanks,

Ingo

2009-10-03 13:23:13

by drago01

[permalink] [raw]
Subject: Re: sched regression introduced by NO_NEW_FAIR_SLEEPERS

On Sat, Oct 3, 2009 at 12:47 PM, Ingo Molnar <[email protected]> wrote:
>
> * drago01 <[email protected]> wrote:
>
>> On Sun, Sep 27, 2009 at 9:47 PM, drago01 <[email protected]> wrote:
>> > Hi,
>> >
>> > Chuck has backported some scheduler patches from 2.6.32 to the fedora kernel.
>> >
>> > I did the following test to test the new scheduler (cpu is a core i7
>> > 920 4 cores + HT).
>> >
>> > run 8 "md5sum /dev/urandom" task and try to use the desktop (compiz).
>> >
>> > The result was that moving windows or rotating the cube is very slow.
>> > (same happens with pure metacity but is is worse in compiz).
>> >
>> > Mounting debugfs and doing "echo NEW_FAIR_SLEEPERS > sched_features"
>> > results into a useable desktop while the 8 md5sum tasks are running
>> > (ie. the system behaves as if they where not running at all from an
>> > interactivity pov).
>> >
>> >
>> > P.S: please CC me when replying.
>> >
>>
>> With "NEW_FAIR_SLEEPERS" I can even run 100(!) ?"md5sum" task without
>> any effect on interactivity. (still have not found a number of tasks
>> needed to make the system unresponsive as with 8 with
>> "NO_NEW_FAIR_SLEEPERS".
>
> Can you try the latest -tip tree please:
>
> ?http://people.redhat.com/mingo/tip.git/README
>
> There we default to FAIR_SLEEPERS + GENTLE_FAIR_SLEEPERS - which should
> give much of the new-fair-sleepers advantage.

OK, with this kernel it works fine (can spam the system with md5sum
tasks and the desktop is still responsive).
Was able to use the system with 129 "md5sum /dev/urandom" running.

2009-10-03 14:50:00

by Ingo Molnar

[permalink] [raw]
Subject: Re: sched regression introduced by NO_NEW_FAIR_SLEEPERS


* drago01 <[email protected]> wrote:

> On Sat, Oct 3, 2009 at 12:47 PM, Ingo Molnar <[email protected]> wrote:
> >
> > * drago01 <[email protected]> wrote:
> >
> >> On Sun, Sep 27, 2009 at 9:47 PM, drago01 <[email protected]> wrote:
> >> > Hi,
> >> >
> >> > Chuck has backported some scheduler patches from 2.6.32 to the fedora kernel.
> >> >
> >> > I did the following test to test the new scheduler (cpu is a core i7
> >> > 920 4 cores + HT).
> >> >
> >> > run 8 "md5sum /dev/urandom" task and try to use the desktop (compiz).
> >> >
> >> > The result was that moving windows or rotating the cube is very slow.
> >> > (same happens with pure metacity but is is worse in compiz).
> >> >
> >> > Mounting debugfs and doing "echo NEW_FAIR_SLEEPERS > sched_features"
> >> > results into a useable desktop while the 8 md5sum tasks are running
> >> > (ie. the system behaves as if they where not running at all from an
> >> > interactivity pov).
> >> >
> >> >
> >> > P.S: please CC me when replying.
> >> >
> >>
> >> With "NEW_FAIR_SLEEPERS" I can even run 100(!) ?"md5sum" task without
> >> any effect on interactivity. (still have not found a number of tasks
> >> needed to make the system unresponsive as with 8 with
> >> "NO_NEW_FAIR_SLEEPERS".
> >
> > Can you try the latest -tip tree please:
> >
> > ?http://people.redhat.com/mingo/tip.git/README
> >
> > There we default to FAIR_SLEEPERS + GENTLE_FAIR_SLEEPERS - which should
> > give much of the new-fair-sleepers advantage.
>
> OK, with this kernel it works fine (can spam the system with md5sum
> tasks and the desktop is still responsive).
>
> Was able to use the system with 129 "md5sum /dev/urandom" running.

ok, great!

Those changes are in Linus's latest tree as well.

Ingo