lkml.org 
[lkml]   [2010]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Kernel rwlock design, Multicore and IGMP
    On Fri, Nov 12, 2010 at 08:27:54AM +0100, Eric Dumazet wrote:
    >Le vendredi 12 novembre 2010 à 15:13 +0800, Américo Wang a écrit :
    >> 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 :
    >> >>
    >> >> Hi
    >> >>
    >> >> CC netdev, since you ask questions about network stuff _and_ rwlock
    >> >>
    >> >>
    >> >>> 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.
    >> >>
    >> >> read_lock() can be nested. We used such a schem in the past in iptables
    >> >> (it can re-enter itself),
    >> >> and we used instead a spinlock(), but with many discussions with lkml
    >> >> and Linus himself if I remember well.
    >> >>
    >> >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.
    >>
    >
    >AFAIK, Lockdep allows read_lock() to be nested.
    >
    >> It is a known weakness of rwlock, it is designed like that. :)
    >>
    >
    >Agreed.
    >

    Just for record, both Tile and X86 implement rwlock with a write-bias,
    this somewhat reduces the write-starvation problem.


    >> The solution is to use RCU or seqlock, but I don't think seqlock
    >> is proper for this case you described. So, try RCU lock.
    >
    >In the IGMP case, it should be easy for the task owning a read_lock() to
    >pass a parameter to the called function saying 'I already own the
    >read_lock(), dont try to re-acquire it'
    >
    >A RCU conversion is far more complex.
    >

    Yup.
    --
    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/

    \
     
     \ /
      Last update: 2010-11-12 09:17    [W:0.027 / U:0.696 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site