[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC][PATCH] scheduler: credit scheduler for client virtualization


  • To: NISHIGUCHI Naoki <nisiguti@xxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
  • Date: Wed, 21 Jan 2009 10:35:10 +0000
  • Cc:
  • Delivery-date: Wed, 21 Jan 2009 02:35:38 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=w+Sd9QmInq1+8QzHl00ji3wIqwYohzY9An3QbDkxOxwtqE2/W719BmIxslnMIC0ay+ PMNHz1rGi8F6jJvOqYJk+R8i576iqkiOc133peLuW0BvEjDD4dGe2XhQ1OdJzDd07IjN v19QG1EBETpD9bz6NvZhMqz5oYBIa4vv9rRCA=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Naoki,

I'm working on revising the scheduler right now, so it's probably best
if you hold off patches for a little while.

I'm also trying to understand the minimum that your client workloads
actually need to run well.  There were compontents of the "boost"
patch series that helped your workload:
 (a) minimum cpu time,
 (b) Shortened time slices (2ms)
 (c) "boosted" priority for multimedia domains

Is it possible that having (a) and (b), possibly with some other
combinations, could work well without adding (c)?

At any rate, I'm going to start with a revised system that has a
minimum cpu time, but no "high priority", and see if we can get things
to work OK without it.

Thanks for your work, BTW -- the scheduler has needed some attention
for a long time, but I don't think it would have gotten it if you
hadn't introduced these patches.

Peace,
 -George

On Wed, Jan 21, 2009 at 3:00 AM, NISHIGUCHI Naoki
<nisiguti@xxxxxxxxxxxxxx> wrote:
> Hi George,
>
> George Dunlap wrote:
>>
>> Sorry, didn't finish my thoughts before sending...
>>
>>> The original meaning of the "boost" priority was a priority given to
>>> domains when waking up, so that latency-sensitive workloads could
>>> achieve low latency when competing with cpu-intensive workloads, while
>>> maintaining weight.  I think this meaning of "boost" (and the
>>> mechanism) is still important, especially for server-style workloads.
>>
>> ...so, I think we need to maintain the old "boost" mechanism (or
>> something like it), and come up with a new name for this "priority cpu
>> time" feature.
>
> I believe that the old "boost" mechanism remains after applying my patches.
> But, now I think that "priority cpu time" feature needs a new name as you
> said.
>
> Because of not changing the existing functionalities in credit scheduler and
> achieving continuous high-priority for a domain, I decided to use "boost"
> mechanism, especially boost priority. In my rev2 patches, old "boost"
> mechanism and "boost credit" I introduced were integrated strongly and the
> good result was obtained. But, as you said and I wrote above, I think that
> the "boost" mechanism and "boost credit" should be separated. I'll try to
> achieve this by introducing new priority for "priority cpu time" feature.
>
> Regards,
> Naoki
>
>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.