From: Srivatsa Vaddagiri <vatsa@in.ibm.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Kirill Korotaev <dev@sw.ru>, Ingo Molnar <mingo@elte.hu>,
Sam Vilain <sam@vilain.net>,
linux-kernel@vger.kernel.org, Kirill Korotaev <dev@openvz.org>,
Mike Galbraith <efault@gmx.de>, Balbir Singh <balbir@in.ibm.com>,
sekharan@us.ibm.com, Andrew Morton <akpm@osdl.org>,
nagar@watson.ibm.com, matthltc@us.ibm.com, dipankar@in.ibm.com
Subject: Re: [PATCH 1/7] CPU controller V1 - split runqueue
Date: Mon, 28 Aug 2006 18:22:41 +0530 [thread overview]
Message-ID: <20060828125241.GA30644@in.ibm.com> (raw)
In-Reply-To: <44F2E216.7090300@yahoo.com.au>
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
next prev parent reply other threads:[~2006-08-28 12:53 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-20 17:40 [PATCH 0/7] CPU controller - V1 Srivatsa Vaddagiri
2006-08-20 17:41 ` [PATCH 1/7] CPU controller V1 - split runqueue Srivatsa Vaddagiri
2006-08-25 12:38 ` Kirill Korotaev
2006-08-28 3:33 ` Srivatsa Vaddagiri
2006-08-28 8:15 ` Kirill Korotaev
2006-08-28 11:03 ` Srivatsa Vaddagiri
2006-08-28 12:31 ` Nick Piggin
2006-08-28 12:52 ` Srivatsa Vaddagiri [this message]
2006-08-20 17:42 ` [PATCH 2/7] CPU controller V1 - define group operations Srivatsa Vaddagiri
2006-08-20 17:44 ` [PATCH 3/7] CPU controller V1 - deal with movement of tasks Srivatsa Vaddagiri
2006-08-20 17:45 ` [PATCH 4/7] CPU controller V1 - Handle dont care groups Srivatsa Vaddagiri
2006-08-20 17:46 ` [PATCH 5/7] CPU controller V1 - Extend smpnice to be task-group aware Srivatsa Vaddagiri
2006-08-20 17:47 ` [PATCH 6/7] CPU controller V1 - task_cpu(p) needs to be correct always Srivatsa Vaddagiri
2006-08-20 17:48 ` [PATCH 7/7] CPU controller V1 - (temporary) cpuset interface Srivatsa Vaddagiri
2006-08-20 20:48 ` Paul Jackson
2006-08-21 17:49 ` Srivatsa Vaddagiri
2006-08-28 1:50 ` Paul Jackson
2006-08-22 11:10 ` Mike Galbraith
2006-08-22 10:10 ` Srivatsa Vaddagiri
2006-08-22 14:41 ` Mike Galbraith
2006-08-22 15:23 ` Mike Galbraith
2006-08-22 14:01 ` Srivatsa Vaddagiri
2006-08-22 18:01 ` Mike Galbraith
2006-08-22 15:58 ` Srivatsa Vaddagiri
2006-08-22 18:55 ` Paul Jackson
2006-08-22 15:45 ` Mike Galbraith
2006-08-22 13:50 ` Srivatsa Vaddagiri
2006-08-22 18:05 ` Mike Galbraith
2006-08-22 16:02 ` Srivatsa Vaddagiri
2006-08-22 19:09 ` Mike Galbraith
2006-08-23 9:43 ` Mike Galbraith
2006-08-23 15:24 ` Mike Galbraith
2006-08-23 13:25 ` Srivatsa Vaddagiri
2006-08-21 10:42 ` [PATCH 0/7] CPU controller - V1 Mike Galbraith
2006-08-21 12:48 ` Srivatsa Vaddagiri
2006-08-21 17:10 ` Mike Galbraith
2006-08-21 16:45 ` Srivatsa Vaddagiri
2006-08-21 20:33 ` Mike Galbraith
2006-08-21 18:36 ` Srivatsa Vaddagiri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060828125241.GA30644@in.ibm.com \
--to=vatsa@in.ibm.com \
--cc=akpm@osdl.org \
--cc=balbir@in.ibm.com \
--cc=dev@openvz.org \
--cc=dev@sw.ru \
--cc=dipankar@in.ibm.com \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=matthltc@us.ibm.com \
--cc=mingo@elte.hu \
--cc=nagar@watson.ibm.com \
--cc=nickpiggin@yahoo.com.au \
--cc=sam@vilain.net \
--cc=sekharan@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.