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/
Home Products Support Community News


RE: [Xen-devel] RE: The caculation of the credit in credit_scheduler

To: Keir Fraser <keir@xxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] RE: The caculation of the credit in credit_scheduler
From: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Date: Fri, 5 Nov 2010 17:33:18 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Delivery-date: Fri, 05 Nov 2010 02:36:09 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C8F96BA8.93F9%keir@xxxxxxx>
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: <BC00F5384FCFC9499AF06F92E8B78A9E1C06EC6BF5@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C8F96BA8.93F9%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Act8t/OXZ6bLDSZ9SFmoF+2ChyNA1QAATszAAAHP70kAArfgUA==
Thread-topic: [Xen-devel] RE: The caculation of the credit in credit_scheduler
Keir Fraser wrote:
> On 05/11/2010 07:26, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx> wrote:
>> Maybe idlers shouldn't produce the credits at the calcuation points.
>> I did an experiment before, it can reduce the unfaireness if idlers
>> not producing credit. 
>> Except this issue, I also have findings and want to share them with
>> you guys to get more input about credit scheduler.
>> 1. Interrupt delivery for assiged devices is done in a tasklet and
>> the tasklet is running in the idle vcpu's context, but scheduler's
>> behavior for scheduling idle vcpu looks very strange. Ideally, when
>> switch to idle vcpu for executing tasklet, the previous vcpu should
>> be switch back after tasklet is done, but current policy is to
>> choose another vcpu in runq.  That is to say, one interrupt happens
>> on one CPU, the CPU may do a real task switch, it maybe not
>> acceptable when interrupt frequency is high and also introduce some
>> performance bugs according to our experiments.  Even if we can
>> switch back the previous vcpu after executing tasklet, how to
>> determine its timeslice for its next run is also a key issue and
>> this is not addressed. If still give 30ms for its restart run, it
>> may trigger some fairness issues, I think.  
> Interrupt delivery is a victim of us switching tasklet implementation
> to work in idle VCPU context instead of in softirq context. It might
> be sensible to make use of softirqs directly from the
> interrupt-delivery logic, or introduce a second type of tasklets
> (built on softirqs), or perhaps we can think of a way to structure
> interrupt delivery that doesn't need softirq context at all -- that
> would be nice! What did we need softirq context for in the first
> place? 

A dedicated softirq maybe a good choice. In this case,  it needs a Per-CPU list 
structure to record the pending interrupts' destinations(which domains). In the 
softirq callback,  it can check the list and delivery the interrupts to guests 
one by one. 

Xen-devel mailing list