linux-kernel - Re: [PATCH 2/2] sched: Improve fairness of cpu allocation for task groups

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, 19 Nov 2007 20:33:12 +0530
From:	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	dmitry.adamushko@...il.com, a.p.zijlstra@...llo.nl,
	dhaval@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
	efault@....de, skumar@...ux.vnet.ibm.com,
	Balbir Singh <balbir@...ibm.com>
Subject: Re: [PATCH 2/2] sched: Improve fairness of cpu allocation for task groups

On Mon, Nov 19, 2007 at 02:12:01PM +0100, Ingo Molnar wrote:
> >  include/linux/sched.h |    4 
> >  kernel/sched.c        |  292 +++++++++++++++++++++++++++++++++++++++++++++-----
> >  kernel/sched_fair.c   |   95 ++++++++++------
> >  kernel/sched_rt.c     |    2 
> >  kernel/sysctl.c       |   16 ++
> >  5 files changed, 348 insertions(+), 61 deletions(-)
> 
> i'm leaning towards making this v2.6.25 material, as it affects the 
> non-group-scheduling bits too and is rather large. When i tested it, 
> group scheduling worked pretty well - at least for CPU bound tasks - and 
> on SMP too. Could we live with what we have for now and defer this patch 
> to v2.6.25?

Hi Ingo,
	I would prefer this to go in 2.6.24 if possible. 2.6.24 would be the
first kernel to support a group scheduler in its entirety (user interface +
related support in scheduler) and also that works reasonably well :) It would 
also give me early test feedback.

> If not, could you split up this patch in a way to defer all 
> the FAIR_GROUP_SCHED relevant changes to a separate patch which will not 
> affect the !FAIR_GROUP_SCHED case at all? That will make the case much 
> clearer.

>From my inspection, here are the changes introduced by this patch
for !CONFIG_FAIR_GROUP_SCHED case:

- inc/dec_load() takes a load input instead of task pointer input as their
  2nd arg
- inc/dec_nr_running don't call inc/dec_load. Instead,
- enqueue/dequeue_task class callbacks call inc/dec_load
- [Unintended/will-fix change] min/max tunables added in
  /proc/sys/kernel

All of above changes (except last, which I will fix) should have zero
functional+runtime effect for !CONFIG_FAIR_GROUP_SCHED case. So I don't see how
I can split Patch 2/2 further.

Or do you prefer I introduce #ifdef's such that even these minor changes to 
inc/dec_load are avoided for !CONFIG_FAIR_GROUP_SCHED case? That would
make the code slightly ugly I suspect.

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