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

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]

Date:	Tue, 13 Mar 2007 08:15:08 -0700
From:	"David Schwartz" <davids@...master.com>
To:	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

> * Mike Galbraith <efault@....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

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