[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH, v2] reduce 'd' debug key's global impact

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.