Re: + spinlock_debug-dont-recompute-jiffies_per_loop.patch added to -mm tree

From: Chuck Ebbert
Date: Thu Jul 27 2006 - 01:56:27 EST

In-Reply-To: <20060725204306.GA22547@xxxxxxx>

On Tue, 25 Jul 2006 22:43:06 +0200, Ingo Molnar wrote:
> * Dave Jones <davej@xxxxxxxxxx> wrote:
> > > iteration limit, gets recomputed every time. Caching it explicitly
> > > prevents that.
> >
> > What is the purpose of those __delays being there at all ? Seems odd
> > to be waiting that long when the spinlock could become available a lot
> > sooner. (These also make spinlock debug really painful on boxes with
> > huge numbers of CPUs).
> the debug code has to figure out when to trigger a deadlock warning
> message. If we are looping in a deadlock with irqs disabled on all CPUs,
> there's nothing that advances jiffies. The TSC is not reliable. The
> thing that remains is to use __delay(1). We could calibrate the loop
> separately perhaps?

Is there some reason this code:

for (i = 0; i < loops_per_jiffy * HZ; i++) {
if (__raw_spin_trylock(&lock->raw_lock))

needs to continuously try to update the spinlock? Shouldn't it just
read it first, like this, to avoid the bus update traffic?

if (spin_can_lock(&lock->raw_lock) &&

Also, looking at __delay(), I foresee problems on i386 with the HPET timer.
Every call to __delay() causes at least two HPET timer reads and it looks
like they're slow (using readl() on ioremapped memory, anyway.)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at