public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox