linux-kernel - RE: [ck] Re: is RSDL an "unfair" scheduler too?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <MDEHLPKNGKAHNMBLJOLKIEFPCFAC.davids@webmaster.com>
Date:	Sat, 17 Mar 2007 10:31:43 -0700
From:	"David Schwartz" <davids@...master.com>
To:	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: RE: [ck] Re: is RSDL an "unfair" scheduler too?



> -----Original Message-----
> From: linux-kernel-owner@...r.kernel.org
> [mailto:linux-kernel-owner@...r.kernel.org]On Behalf Of jos poortvliet
> Sent: Saturday, March 17, 2007 5:24 AM
> To: ck@....kolivas.org
> Cc: Con Kolivas; Ingo Molnar; Al Boldi; Mike Galbraith;
> linux-kernel@...r.kernel.org; Nicholas Miell; Linus Torvalds; Andrew
> Morton
> Subject: Re: [ck] Re: is RSDL an "unfair" scheduler too?
>
>
> Op Saturday 17 March 2007, schreef Con Kolivas:
> > On Saturday 17 March 2007 22:49, Ingo Molnar wrote:
> > > * Con Kolivas <kernel@...ivas.org> wrote:
> > > > Despite the claims to the contrary, RSDL does not have _less_
> > > > heuristics, it does not have _any_. It's purely entitlement based.
> > >
> > > RSDL still has heuristics very much, but this time it's hardcoded into
> > > the design! Let me demonstrate this via a simple experiment.
> > >
> > > in the vanilla scheduler, the heuristics are ontop of a fairly basic
> > > (and fast) scheduler, they are plain visible and thus 'optional'. In
> > > RSDL, the heuristics are still present but more hidden and more
> > > engrained into the design.
> > >
> > > But it's easy to demonstrate this under RSDL: consider the
> following two
> > > scenarios, which implement precisely the same fundamental computing
> > > workload (everything running on the same, default nice 0 level):
> > >
> > > 1) a single task runs almost all the time and sleeps about 1
> msec every
> > >    100 msecs.
> > >
> > >    [ run "while N=1; do N=1; done &" under bash to create such a
> > >      workload. ]
> > >
> > > 2) tasks are in a 'ring' where each runs for 100 msec, sleeps for 1
> > >    msec and passes the 'token' around to the next task in the
> ring. (in
> > >    essence every task will sleep 9900 msecs before getting
> another run)
> > >
> > >    [ run http://redhat.com/~mingo/scheduler-patches/ring-test.c to
> > >      create this workload. If the 100 tasks default is too
> much for you
> > >      then you can run "./ring-test 10" - that will show
> similar effects.
> > >    ]

> Well, re-reading his post, he has a point - one WOULD expect each
> of these 2
> tasks to have an equal share of CPU, and if RSDL doesn't
> currently take this
> pipe-thing into account, it might need some fixing. call it
> heuristics or not
> (after all, how could one NOT say a scheduler uses heuristics of
> some kind?).

I can't get myself to expect that no matter how hard I try. The scheduler
is, by design, fair to *tasks*. So why would one expect two different
approaches that do the same thing, but with different numbers of tasks, to
each get the same amount of CPU if they compete with each other? One would
expect the approach that uses the most tasks to get more CPU.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/