[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071119150312.GA2365@linux.vnet.ibm.com>
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/
Powered by blists - more mailing lists