Messages in this thread | | | Date | Mon, 28 Aug 2006 18:22:41 +0530 | From | Srivatsa Vaddagiri <> | Subject | Re: [PATCH 1/7] CPU controller V1 - split runqueue |
| |
On Mon, Aug 28, 2006 at 10:31:18PM +1000, Nick Piggin wrote: > I still haven't had much time to look at the implementation, but this > design seems cleanest I've considered, IMO. > > Of course I would really hope we don't need any special casing in the > SMP balancing (which may be the tricky part). However hopefully if > things don't work well in that department, they can be made to by > improving the core code to be more general rather than special casing. > > Do you have a better (/another) idea for the design?
I dont' know if it is a better idea - but I have been trying to experiment with some token-based system where task-groups run until exhausted out of their tokens. Of course, this will be work-conserving in the sense that expired task-groups continue running if there arent others who want to use their share. Token are renewed at periodic intervals. I believe that is how vserver scheduler works (though havent looked at their code).
And I was thinking of using something similar to smpnice for load-balance purposes.
The main point here is that scheduling next-task-group decision is local to each CPU (very similar to how next-task is picked up currently), with some load-balance code expected to balance tasks/task-groups across all CPUs.
In what Kirill is proposing, this "scheduling next-task-group decision" on each CPU perhaps takes a global view and because of the physical/virtual CPU separation, any CPU can be running any other CPU's tasks (smp_processor_id/get_cpu etc now returning virtual CPU number rather than the actual CPU on which they are running). Kirill is that description correct?
-- Regards, vatsa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |