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] [RFC] Add static priority into credit scheduler

To: NISHIGUCHI Naoki <nisiguti@xxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [RFC] Add static priority into credit scheduler
From: "Su, Disheng" <disheng.su@xxxxxxxxx>
Date: Fri, 27 Mar 2009 16:05:45 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: George Dunlap <dunlapg@xxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Su, Disheng" <disheng.su@xxxxxxxxx>
Delivery-date: Fri, 27 Mar 2009 01:07:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49CC7A30.4070202@xxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <BB1F052FCDB1EA468BD99786C8B1ED2C01DC1424F2@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <de76405a0903200542j8c19bdu86f401d28bc07ae8@xxxxxxxxxxxxxx> <BB1F052FCDB1EA468BD99786C8B1ED2C01DC1429D6@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <de76405a0903250335r3b2dbb5at589d2a999f118b5a@xxxxxxxxxxxxxx> <49CC3C6A.6050308@xxxxxxxxxxxxxx> <BB1F052FCDB1EA468BD99786C8B1ED2C01DC444759@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <49CC7A30.4070202@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcmuqivRL2/W+T8PQTS4JGi3q2qB1gAAFY+Q
Thread-topic: [Xen-devel] [RFC] Add static priority into credit scheduler
NISHIGUCHI Naoki wrote:
> I understand what you mean.
> I doubt whether the rest of cpu not used by RT guest is reflected to
> credit of non-RT guests. If RT guest might monopolize the whole cpu, I
> think the rest of cpu is nothing, therefore non-RT guests have no
> credit. 
> 

Yes, it's an issue need to be addressed for client virtualization case, due to 
the primary guest(e,g Windows) is not a trusted guest.
When detecting one RT guest is monopolize cpu for a while(e.g. 1-2minute), one 
can:
1. kill the RT guest...
2. lower its priority for a while, give other guests the opportunity to run, 
then restore its previous priority
Any ideas? 

> As you sad, I set dom0 and HVM to RT priority(1) and tested.
> Regretfully, HVM does not work well.
> 
> Attached file is output of "xm debug-keys r".
> 

Oh, forgot to mention you need to pin the RT guest, or try the attached patch.
If you set one guest as high priority, it increases the chance that its vcpus 
are migrated back and forth, because the priority is fixed and higher than  
OVER.
Don't migrate the RT guest in practice. It's the same with Bcredit from my 
previous experience, isn't it?


> Best regards,
> Naoki Nishiguchi



Best Regards,
Disheng, Su

Attachment: dont_migrate_for_rt_dom.patch
Description: dont_migrate_for_rt_dom.patch

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