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]

Message-ID: <Pine.LNX.4.63.0703122152520.1855@qynat.qvtvafvgr.pbz>
Date:	Mon, 12 Mar 2007 22:00:51 -0800 (PST)
From:	David Lang <david.lang@...italinsight.com>
To:	Lee Revell <rlrevell@...-job.com>
cc:	Mike Galbraith <efault@....de>, Con Kolivas <kernel@...ivas.org>,
	Ingo Molnar <mingo@...e.hu>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	ck list <ck@....kolivas.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

On Mon, 12 Mar 2007, Lee Revell wrote:

> On 3/12/07, David Lang <david.lang@...italinsight.com> wrote:
>> the problem comes when this isn't enough. if you have several CPU hogs on a
>> system, and they are all around the same priority level, how can the 
>> scheduler
>> know which one needs the CPU the most for good interactivity?
>> 
>> in some cases you may be able to directly detect that your high-priority 
>> process
>> is waiting for another one (tracing pipes and local sockets for example), 
>> but
>> what if you are waiting for several of them? (think a multimedia desktop 
>> waiting
>> for the sound card, CDRom, hard drive, and video all at once) which one 
>> needs
>> the extra CPU the most?
>
> I'm not an expert in this area by any means but after reading this
> thread the OSX solution of simply telling the kernel "I'm the GUI,
> schedule me accordingly" looks increasingly attractive.  Why make the
> kernel guess when we can just be explicit?

this can solve the specific problem (and since 'nice' is the natural way to tell 
the kernel this, it's not even a one-shot solution).

however Linus is right, the real underlying problem is where the user is 
waiting on a server. if this issue could be solved then a lot of things would 
benifit.

Con, as a quick hack (probably a bad idea as I'm not a scheduling expert), if a 
program blocks on another program (via a pipe or socket) could you easily give 
the rest of the first program's timeslice to the second one, without makeing it 
loose it's own?

I'm thinking that doing the dumb thing and just throwing a bit more CPU at the 
thing you are waiting for may work. (assuming that the server process actually 
does something useful with the extra CPU time it gets)

as far as latencies go, it would be like turning every process on the system 
into a cpu hog.

David Lang

> Does anyone know of a UNIX-like system that has managed to solve this
> problem without hooking the GUI into the scheduler?
>
> Lee
>
-
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/