Messages in this thread | | | Date | Mon, 15 Nov 2010 15:22:02 +0800 | Subject | Re: Kernel rwlock design, Multicore and IGMP | From | Cypher Wu <> |
| |
On Sun, Nov 14, 2010 at 7:03 AM, Chris Metcalf <cmetcalf@tilera.com> wrote: > On 11/12/2010 2:13 AM, Américo Wang wrote: >> On Fri, Nov 12, 2010 at 11:32:59AM +0800, Cypher Wu wrote: >>> On Thu, Nov 11, 2010 at 11:23 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote: >>>> Le jeudi 11 novembre 2010 à 21:49 +0800, Cypher Wu a écrit : >>>>> I'm using TILEPro and its rwlock in kernel is a liitle different than >>>>> other platforms. It have a priority for write lock that when tried it >>>>> will block the following read lock even if read lock is hold by >>>>> others. Its code can be read in Linux Kernel 2.6.36 in >>>>> arch/tile/lib/spinlock_32.c. >>>> >>>> This seems a bug to me. >>>> [...] >>>> >>> It seems not a problem that read_lock() can be nested or not since >>> rwlock doesn't have 'owner', it's just that should we give >>> write_lock() a priority than read_lock() since if there have a lot >>> read_lock()s then they'll starve write_lock(). >>> We should work out a well defined behavior so all the >>> platform-dependent raw_rwlock has to design under that principle. >> >> It is a known weakness of rwlock, it is designed like that. :) > > Exactly. The tile rwlock correctly allows recursively reacquiring the read > lock. But it does give priority to writers, for the (unfortunately > incorrect) reasons Cypher Wu outlined above, e.g.: > > - Core A takes a read lock > - Core B tries for a write lock and blocks new read locks > - Core A tries for a (recursive) read lock and blocks > > Core A and B are now deadlocked. > > The solution is actually to simplify the tile rwlock implementation so that > both readers and writers contend fairly for the lock. > > I'll post a patch in the next day or two for tile. > > -- > Chris Metcalf, Tilera Corp. > http://www.tilera.com >
We're looking forward to you patch. BTW: could your fix it up in Linux 2.6.26.7 which is not release in the normal kernel?
-- Cyberman Wu http://www.meganovo.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |