All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Dong, Eddie" <eddie.dong@intel.com>,
	"Lv, Hui" <hui.lv@intel.com>,
	"Duan, Jiangang" <jiangang.duan@intel.com>
Subject: Re: [PATCH] scheduler rate controller
Date: Tue, 25 Oct 2011 09:57:17 +0200	[thread overview]
Message-ID: <1319529437.2230.63.camel@Abyss> (raw)
In-Reply-To: <CAFLBxZZ9nqeb7CVqTZCsEtJRjgGMTHF2Ak929kvauj2KUFSOyg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2523 bytes --]

Hello everyone,

On Mon, 2011-10-24 at 17:17 +0100, George Dunlap wrote:
> * The actual algorithm you use here isn't described.  It seems to be
> as follows (please correct me if I've made a mistake
> reverse-engineering the algorithm):
> 
> Every 10ms, check to see if there have been more than 50 schedules.
> If so, disable pre-emption entirely for 10ms, allowing processes to
> run without being interrupted (unless they yield).
> 
> It seems like we should be able to do better.  For one, it means in
> the general case you will flip back and forth between really frequent
> schedules and less frequent schedules.  For two, turning off
> preemption entirely will mean that whatever vcpu happens to be running
> could, if it wished, run for the full 10ms; and which one got elected
> to do that would be really random.  
>
To me, this is  key point... Maybe we can save at least the calls coming
from the timer tick from being skipped, or something like that?

More generally speaking, I think I can see how this feature can be
useful, and I also think it can live in the generic schedule.c code, but
the algorithm with which rate-limiting is happening needs to be well
known, documented and exposed to the user (more than by means of a
couple of perf-counters).

For example this might completely destroy the time guarantees a
scheduler  like sEDF would give, and in such case it must be easy enough
to figure out what's going on and why the scheduler is  not behaving as
one would have expected!

For that reaason, although, again, a mechanism like this could
(according to my opinion) be general enough to be sensible and
meaningful for all the various schedulers, it might be worthwhile to
have it inside credit1 for now, where we know it will probably yield the
most of its benefits.

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

  parent reply	other threads:[~2011-10-25  7:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-24  3:36 [PATCH] scheduler rate controller Lv, Hui
2011-10-24 16:17 ` George Dunlap
2011-10-24 16:57   ` Keir Fraser
2011-10-24 21:20   ` Dario Faggioli
2011-10-25  7:57   ` Dario Faggioli [this message]
2011-10-28  2:07   ` Lv, Hui
2011-10-28  8:10     ` Dario Faggioli
2011-10-28  8:52       ` Lv, Hui
2011-10-28 10:09         ` Dario Faggioli
2011-10-28 16:18           ` George Dunlap
2011-10-29  2:05             ` Lv, Hui
2011-10-31 10:16               ` Dario Faggioli
2011-11-03  4:28               ` George Dunlap
2011-11-04 14:08                 ` Lv, Hui
2011-11-14 15:22                   ` George Dunlap
2011-11-14 15:30                   ` George Dunlap
2011-11-28 17:31                 ` Lv, Hui
2011-12-01 17:13                   ` George Dunlap
2011-12-11 15:27                     ` Lv, Hui
2011-12-12 11:43                       ` George Dunlap
2011-12-13  2:24                         ` Lv, Hui
2011-10-31  9:59             ` Dario Faggioli

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=1319529437.2230.63.camel@Abyss \
    --to=raistlin@linux.it \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=eddie.dong@intel.com \
    --cc=hui.lv@intel.com \
    --cc=jiangang.duan@intel.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=xen-devel@lists.xensource.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.