lkml.org 
[lkml]   [2008]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH RFC 4/4] xen: implement Xen-specific spinlocks
Date
Hi,

Jeremy Fitzhardinge <jeremy@goop.org> writes:

> Johannes Weiner wrote:
>>> +static DEFINE_PER_CPU(int, lock_kicker_irq) = -1;
>>> +static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners);
>>>
>>
>> The plural is a bit misleading, as this is a single pointer per CPU.
>>
>
> Yeah. And it's wrong because it's specifically *not* spinning, but
> blocking.

I thought of it as `virtually spinning', so had no problems with the
naming itself :)

>>> +static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
>>> +{
>>> + int cpu;
>>> +
>>> + for_each_online_cpu(cpu) {
>>>
>>
>> Would it be feasible to have a bitmap for the spinning CPUs in order to
>> do a for_each_spinning_cpu() here instead? Or is setting a bit in
>> spinning_lock() and unsetting it in unspinning_lock() more overhead than
>> going over all CPUs here?
>>
>
> Not worthwhile, I think. This is a very rare path: it will only
> happen if 1) there's lock contention, that 2) wasn't resolved within
> the timeout. In practice, this gets called a few thousand times per
> cpu over a kernbench, which is nothing.

Okay, I agree.

Hannes


\
 
 \ /
  Last update: 2008-07-08 09:33    [W:0.048 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site