public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Srivatsa Vaddagiri <vsrivatsa@gmail.com>
To: mingo@elte.hu
Cc: george@mvista.com, nickpiggin@yahoo.com.au,
	high-res-timers-discourse@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, vatsa@in.ibm.com
Subject: Re: VST and Sched Load Balance
Date: Thu, 7 Apr 2005 21:55:13 +0530	[thread overview]
Message-ID: <36c1843405040709252bd07696@mail.gmail.com> (raw)

[Sorry about sending my response from a different account. Can't seem
to access my ibm account right now]

* Ingo wrote:

> Another, more effective, less intrusive but also more complex approach
> would be to make a distinction between 'totally idle' and 'partially
> idle or busy' system states. When all CPUs are idle then all timer irqs
> may be stopped and full VST logic applies. When at least one CPU is
> busy, all the other CPUs may still be put to sleep completely and
> immediately, but the busy CPU(s) have to take over a 'watchdog' role,
> and need to run the 'do the idle CPUs need new tasks' balancing
> functions. I.e. the scheduling function of other CPUs is migrated to
> busy CPUs. If there are no busy CPUs then there's no work, so this ought
> to be simple on the VST side. This needs some reorganization on the
> scheduler side but ought to be doable as well.


Hmm ..I think this is the approach that I have followed in my patch, where
busy CPUs act as watchdogs and wakeup sleeping CPUs at an appropriate
time. The appropriate time is currently based on the busy CPU's load
being greater than 1 and the sleeping CPU not having balanced for its
minimum balance_interval.

Do you have any other suggestions on how the watchdog function should
be implemented?

- vatsa

             reply	other threads:[~2005-04-07 16:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-07 16:25 Srivatsa Vaddagiri [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-04-07 12:46 VST and Sched Load Balance Srivatsa Vaddagiri
2005-04-07 13:07 ` Nick Piggin
2005-04-07 14:00   ` Srivatsa Vaddagiri
2005-04-07 14:06     ` Nick Piggin
2005-05-05 14:39   ` Srivatsa Vaddagiri
2005-05-05 14:52     ` Nick Piggin
2005-05-05 16:15       ` Srivatsa Vaddagiri
2005-04-07 15:10 ` Ingo Molnar
2005-04-08  5:34   ` Srivatsa Vaddagiri
2005-04-08  6:33     ` Nick Piggin
2005-04-19 16:07 ` Nish Aravamudan
2005-04-20  9:11   ` 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=36c1843405040709252bd07696@mail.gmail.com \
    --to=vsrivatsa@gmail.com \
    --cc=george@mvista.com \
    --cc=high-res-timers-discourse@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=vatsa@in.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