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] [PATCH, v2] reduce 'd' debug key's global impact

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH, v2] reduce 'd' debug key's global impact
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Thu, 6 May 2010 10:15:03 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 06 May 2010 02:15:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4BE2A2FE020000780000186C@xxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acrs+6bnQ3K1/dUGRRCDzMQWdiJHTwAAPVOY
Thread-topic: [Xen-devel] [PATCH, v2] reduce 'd' debug key's global impact
User-agent: Microsoft-Entourage/
On 06/05/2010 10:07, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

>>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 06.05.10 10:01 >>>
>> Although I suppose the event-check vector has a cleaner interface for
>> calling it and should be implemented for all architectures. If you add
>> whatever new flag you need to irq_cpustat_t then it would be cheap to check,
>> being a definite cache hit. I suppose each cpu would
> Actually, in smp_event_check_interrupt(), irq_cpustat isn't being used
> so far, so placing the new field there wouldn't be a definite cache hit.
> Instead (if that has to remain, which I doubt) co-locating it with
> __irq_regs would help here.

The most interesting exit path out of the handler via ret_from_intr will
pass through test_all_events (because that indicates a busy CPU running a
guest, and in that case we are most likely to have interrupted guest
context). In that case we pull in the irqstat cacheline to check
softirq_pending. Other exit paths indicate idle CPU (don't care so much
about that) or interrupted hypervisor context (should be rarer than running
in guest context for a non-idle CPU).

> Otoh it seems like I will should add irq_enter()/irq_exit() now that the
> function calls something non-trivial...

Yes, most definitely. They are cheap and should be added unconditionally to
the handler if you go this route.

 -- Keir

Xen-devel mailing list