linux-kernel - Re: [ck] 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:	Mon, 12 Mar 2007 22:34:57 +0100
From:	jos poortvliet <jos@...nkamer.nl>
To:	ck@....kolivas.org
Cc:	Con Kolivas <kernel@...ivas.org>, Mike Galbraith <efault@....de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [ck] Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

Op Monday 12 March 2007, schreef Con Kolivas:
> > > If we fix 95% of the desktop and worsen 5% is that bad given how much
> > > else we've gained in the process?
> >
> > Killing the known corner case starvation scenarios is wonderful, but
> > let's not just pretend that interactive tasks don't have any special
> > requirements.
>
> Now you're really making a stretch of things. Where on earth did I say that
> interactive tasks don't have special requirements? It's a fundamental
> feature of this scheduler that I go to great pains to get them as low
> latency as possible and their fair share of cpu despite having a completely
> fair cpu distribution.

As far as I understand it, RSDL always gives an equal share of cpu, but 
interactive tasks can have lower latency, right? So you get in trouble with 
interactive tasks only when their share isn't enough to actually do what they 
have to do in that period, eg on a heavily (over?) loaded box. Staircase, 
like mainline which gave them MORE than their share, would support that 
(though this comes at a price).

So, if your box is overloaded to a great extend, X, which can use a lot of 
cpu, can get unresponsive - unless it's negatively niced. But most other apps 
aren't as demanding as X is, so they won't really suffer. Thus the problem is 
mostly X. And at least part of that problem is being solved - X wasting cpu 
cycles. Also, cpu's are getting stronger, and I think it's likely X's 
relative CPU usage goes down as well.

In the long term, RSDL seems like the best way to go. Nice X down, and you got 
most of the disadvantages. You still have the perfect fairness, no stalls and 
starvation ;-)

If RSDL can be improved to help X, great. But introducing again the problem 
which RSDL was supposed to solve would be pretty pointless. I think that's 
what grumpy Con is trying to say, and he's right at it.

grtz

Jos

-- 
Disclaimer:

Alles wat ik doe denk en zeg is gebaseerd op het wereldbeeld wat ik nu heb. 
Ik ben niet verantwoordelijk voor wijzigingen van de wereld, of het beeld wat 
ik daarvan heb, noch voor de daaruit voortvloeiende gedragingen van mezelf. 
Alles wat ik zeg is aardig bedoeld, tenzij expliciet vermeld.

Content of type "application/pgp-signature" skipped