linux-kernel - Re: [ RFC, PATCH 1/5 ] CPU controller

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: <20060804145158.GA29850@in.ibm.com>
Date:	Fri, 4 Aug 2006 20:21:58 +0530
From:	Srivatsa Vaddagiri <vatsa@...ibm.com>
To:	Kirill Korotaev <dev@...ru>
Cc:	Ingo Molnar <mingo@...e.hu>, Nick Piggin <nickpiggin@...oo.com.au>,
	Sam Vilain <sam@...ain.net>, linux-kernel@...r.kernel.org,
	Kirill Korotaev <dev@...nvz.org>,
	Mike Galbraith <efault@....de>,
	Balbir Singh <balbir@...ibm.com>, sekharan@...ibm.com,
	Andrew Morton <akpm@...l.org>, nagar@...son.ibm.com,
	haveblue@...ibm.com, pj@....com
Subject: Re: [ RFC, PATCH 1/5 ] CPU controller - base changes

On Fri, Aug 04, 2006 at 06:34:00PM +0400, Kirill Korotaev wrote:
> Srivatsa,
> 
> AFAICS, you wanted to go the way we used in OpenVZ - 2-level scheduling.
> However, you don't do any process balancing between runqueues taking into 
> account
> other groups.
> In many cases you will simply endup with tasks collected on the same 
> physical
> CPU and poor performance. I'm not talking about fairness (proportinal CPU 
> scheduling).

> I don't think it is possible to make any estimations for QoS of such a 
> scheduler.

Yes, the patch (as mentioned earlier) does not address SMP correctness
_yet_. That will need to be addressed definitely for an acceptable
controller. My thought was we could try the smpnice approach (which
attempts to deal with the same problem albeit for niced tasks) and
see how far we can go. I am planning to work on it next.

> What do you think about a full runqueue virtualization, so that
> first level CPU scheduler could select task-group on any basis and then
> arbitrary runqueue was selected for running?

That may solve the load balance problem nicely. But isnt there some cost
to be paid for it (like lock contention on the virtual runqueues)?

> P.S. BTW, this patch doesn't allow hierarchy in CPU controler.

Do we want heriarchy?


-- 
Regards,
vatsa
-
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/