LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Fwd: [PATCH 2/7] lock_list: a fine grain locked double linked list]
Date: Mon, 29 Jan 2007 11:20:40 +0100	[thread overview]
Message-ID: <1170066040.6189.128.camel@twins> (raw)
In-Reply-To: <20070128172027.GA4913@infradead.org>

On Sun, 2007-01-28 at 17:20 +0000, Christoph Hellwig wrote:
> > Provide a simple fine grain locked double link list.
> > 
> > It is build upon the regular double linked list primitives, spinlocks and RCU.
> > 
> > Locking is peculiar in that edges are locked, this avoid the circular lock
> > dependancy created by the fact that the regular linked lists are circular.
> > 
> > Item deletion requires that both surrounding elements are locked, however since
> > the locking rules dictate that we lock elements in a single direction we have
> > to lock the previous element while it might be deleted under us. Hence the
> > requirement that all elements are RCU freed.
> 
> I think implicitly locked data structures are very bad for code readability
> and debugability.  What's even worse here is that we have a requirement that
> all members are RCU freed.
> 
> Note that we also have another implicitly locked (and refcounted) list
> implementation in klist.[ch] - if we find consensus that we want implicitly
> locked list we should figure out whether we want lock_list or klist semantics
> and stick to one of them.

klist is quite different in that it locks the whole list. The proposed
data structure locks each edge, that is it will allow concurrent
deletion of elements as long as they don't share neighbours.

> What uses do you have planned for this data structure?  In general I think
> we'd be better off to simplify the data structures as in my files_list_lock
> proposal instead of complicating the locking.

Getting rid of the s_files list like you proposed would of course be a
much better solution, and I'll look into that.

Not having the VFS knowledge you do I just smashed the lock and kept
current semantics.


  reply	other threads:[~2007-01-29 10:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-28 15:53 Peter Zijlstra
2007-01-28 17:20 ` Christoph Hellwig
2007-01-29 10:20   ` Peter Zijlstra [this message]
2007-01-29 10:25     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1170066040.6189.128.camel@twins \
    --to=a.p.zijlstra@chello.nl \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [Fwd: [PATCH 2/7] lock_list: a fine grain locked double linked list]' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).