Re: [Xen-devel] [PATCH 2/2] x86/HVM: batch vCPU wakeups

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.09.14 at 12:48, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 11/09/14 10:40, Jan Beulich wrote:
>>  void cpu_raise_softirq(unsigned int cpu, unsigned int nr)
>>  {
>> -    if ( !test_and_set_bit(nr, &softirq_pending(cpu))
>> -         && (cpu != smp_processor_id())
>> -         && !arch_skip_send_event_check(cpu) )
>> +    unsigned int this_cpu = smp_processor_id();
>> +
>> +    if ( test_and_set_bit(nr, &softirq_pending(cpu))
>> +         || (cpu == this_cpu)
>> +         || arch_skip_send_event_check(cpu) )
>> +        return;
>> +
>> +    if ( !per_cpu(batching, this_cpu) || in_irq() )
>>          smp_send_event_check_cpu(cpu);
>> +    else
>> +        set_bit(nr, &per_cpu(batch_mask, this_cpu));
> 
> Under what circumstances would it be sensible to batch calls to
> cpu_raise_softirq()?
> 
> All of the current callers are singleshot events, and their use in a
> batched period would only be as a result of a timer interrupt, which
> bypasses the batching.

You shouldn't be looking at the immediate callers of
cpu_raise_softirq(), but at those much higher up the stack.
Rooted at vlapic_ipi(), depending on the scheduler you might
end up in credit1's __runq_tickle() (calling cpumask_raise_softirq())
or credit2's runq_tickle() (calling cpu_raise_softirq()).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel