WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Getting and setting SEDF scheduling parameters

To: John L Griffin <jlg@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Getting and setting SEDF scheduling parameters
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 06 Jan 2006 10:37:35 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 06 Jan 2006 10:43:14 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: Your message of "Thu, 05 Jan 2006 14:26:14 EST." <OF56748F8E.8A763F25-ON852570ED.0068B675-852570ED.006AC522@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> Note that this patch makes strong assumptions about how the scheduling 
> parameters are used.  So, I recommend someone take a really close look at 
> my comments to make sure I've preserved the Xen team's intentions for how 
> the SEDF scheduler works. :-)

I think that the current GET/PUT_INFO call is definitely screwed. The
intended use of extratime should be to allow time-driven domains to
get a best-effort weighted slice of otherwise-idle cpu. Extratime is
not a completely separate scheduling category in its own right! :-)

The scheduling logic should be something like: (a) schedule runnable
time-driven domains with time slice left; then (b) schedule runnable
weight-driven domains; then (c) schedule extratime-aware time-driven
domains. Apart from this there is a bunch of scheduler complexity to
try and sanely handle I/O workloads (short-blocking domains).

Depending on how unused time slices are divvied up, it may make sense
to allow real-time-weight-driven domains also to specify
extratime-awareness (depends on whether real-time weights divvy up all
available cpu (non-time-sliced and unused time-sliced), or just the
spare non-time-sliced time according to the predetermined schedule).

 -- Keir

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