[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080801211043.GW14851@linux.vnet.ibm.com>
Date: Fri, 1 Aug 2008 14:10:43 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Nick Piggin <nickpiggin@...oo.com.au>
Cc: Miklos Szeredi <miklos@...redi.hu>, peterz@...radead.org,
davem@...emloft.net, jarkao2@...il.com, Larry.Finger@...inger.net,
kaber@...sh.net, torvalds@...ux-foundation.org,
akpm@...ux-foundation.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org,
mingo@...hat.com
Subject: Re: Kernel WARNING: at net/core/dev.c:1330
__netif_schedule+0x2c/0x98()
On Thu, Jul 24, 2008 at 09:06:51PM +1000, Nick Piggin wrote:
> On Thursday 24 July 2008 20:55, Miklos Szeredi wrote:
> > On Thu, 24 Jul 2008, Nick Piggin wrote:
> > > Hey, something kind of cool (and OT) I've just thought of that we can
> > > do with ticket locks is to take tickets for 2 (or 64K) nested locks,
> > > and then wait for them both (all), so the cost is N*lock + longest spin,
> > > rather than N*lock + N*avg spin.
> >
> > Isn't this deadlocky?
> >
> > E.g. one task takes ticket x=1, then other task comes in and takes x=2
> > and y=1, then first task takes y=2. Then neither can actually
> > complete both locks.
>
> Oh duh of course you still need mutual exclusion from the first lock
> to order the subsequent :P
>
> So yeah it only works for N > 2 locks, and you have to spin_lock the
> first one... so unsuitable for scheduler.
Or sort the locks by address or some such.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists