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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/