[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C0E00F6.8020409@redhat.com>
Date: Tue, 08 Jun 2010 16:36:06 +0800
From: Cong Wang <amwang@...hat.com>
To: David Miller <davem@...emloft.net>
CC: andy@...yhouse.net, fubar@...ibm.com, fbl@...close.org,
linux-kernel@...r.kernel.org, mpm@...enic.com,
netdev@...r.kernel.org, bridge@...ts.linux-foundation.org,
gospo@...hat.com, nhorman@...driver.com, jmoyer@...hat.com,
shemminger@...ux-foundation.org,
bonding-devel@...ts.sourceforge.net
Subject: Re: [v5 Patch 1/3] netpoll: add generic support for bridge and bonding
devices
On 06/07/10 18:01, David Miller wrote:
> From: Cong Wang<amwang@...hat.com>
> Date: Mon, 07 Jun 2010 17:57:49 +0800
>
>> Hmm, I still feel like this way is ugly, although it may work.
>> I guess David doesn't like it either.
>
> Of course I don't like it. :-)
>
> I suspect the locking scheme will need to be changed.
>
> Besides, if we're going to hack this up and do write lock attempts in
> the read locking paths, there is no point in using a rwlock any more.
> And I'm personally in disfavor of all rwlock usage anyways (it dirties
> the cacheline for readers just as equally for writers, and if the
> critically protected code path is short enough, that shared cache
> line atomic operation will be the predominant cost).
>
> So I'd say, 1) make this a spinlock and 2) try to use RCU for the
> read path.
>
> That would fix everything.
Yeah, agreed. Even not talking about netconsole, bonding code
does have locking problems, netconsole just makes this problem
clear.
I will try your suggestions above.
Thanks!
--
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