|
xen-devel
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.
Xiantao
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home