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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 11/09/14 12:03, Jan Beulich wrote:
>>>> 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
>

Ah true, which is valid to batch.

Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

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