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: "Su, Disheng" <disheng.su@xxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] Add static priority into credit scheduler
From: NISHIGUCHI Naoki <nisiguti@xxxxxxxxxxxxxx>
Date: Fri, 27 Mar 2009 19:13:59 +0900
Cc: George Dunlap <dunlapg@xxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 27 Mar 2009 03:14:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BB1F052FCDB1EA468BD99786C8B1ED2C01DC444924@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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> <BB1F052FCDB1EA468BD99786C8B1ED2C01DC444924@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)
Su, Disheng wrote:
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?

What I mean is credit_total given to non-RT guest in scheduler.
If a PC has 4 core cpu and an RT guest has 4 vcpu, I think credit_total would be 0, because we could not predict behavior of the RT guest .

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.

I tried your patch. The result was the same.
I also pin the RT guest and dom0 as follows, but HVM did not work well.
            vcpu cpu
     dom0     0   0
              1   1
              2   2
              3   3
     HVM      0   0
              1   1
              2   2
              3   3

It seems to me that idle cpus are not effectively used.

Don't migrate the RT guest in practice. It's the same with Bcredit from my 
previous experience, isn't it?

I think that scheduler should not migrate the vcpu needlessly, but necessary migration should be done.

Best regards,
Naoki Nishiguchi


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