Re: [PATCH] XATTR issues on JFFS2

[Kaigai Kohei <kaigai@ak.jp.nec.com>]

Hi,

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.

Thanks,
-- 
Linux Promotion Center, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>