[PATCH] XATTR issues on JFFS2

[Jörn Engel]

On Thu, 25 August 2005 19:28:42 +0900, Kaigai Kohei wrote:
> 
> Today, I think about appropriate locking in JFFS2's XATTR.
> I hope to get some comments about dividing locking.
> 
> >* Dividing the global xattr_sem semaphore into more small lock.
> 
> xattr_sem is a global read/write semaphore stored in jffs2_sb_info
> to protect any XATTR structure.
> In common case, dividing lock/semaphore has good effects for scalability
> toward the number of CPUs. But JFFS2 is frequently used for small
> and embedded region in my understanding.
> 
> If global semaphore is divided into many per-entry locks, we may be able
> to execute setxattr() concurrently. But each locking/un-locking cost
> may also exceed the scalability effect.
> Since I don't have much experience in this region, I hope any professional's
> worthwhile comments.
> 
> Now, I think one global read/write semaphore is enough for 1-2 CPUs,
> if assumption of the XATTR processing with wrinting does not happen
> so much is permitted.  In almost case, we can execute get/listxattr
> cuncurrently with one lock/un-locking, I think.

Your idea to go to fine-grained locking surprised me a bit when I
first saw it.  JFFS2 is hardly the fs that cares much about SMP
scalability.  Unless you can prove real contentions around the
xattr_lock in realistic benchmarks, I would ignore this issue.

Correctness is another issue.  I guess you have read
fs/jffs2/README.Locking and started a graph on paper to visualize
locking order.  This is more important, as a deadlock is about the
worst performance you can get. ;)

Jörn

-- 
He that composes himself is wiser than he that composes a book.
-- B. Franklin