Re: JFFS3 & performance

Jörn Engel
2005-01-21T13:42:19Z

On Fri, 21 January 2005 13:13:14 +0000, Artem B. Bityuckiy wrote:
>
> I would like create TeX file and put this "JFFS3 checkusm stuff" there.
> This will be "JFFS3 design issues file". It will be accessible via CVS and
> people may edit it, contributing new ideas.

Sounds good.

> More questions which I would like to discuss are:
>
> * JFFS3 memory consumption

Good idea.

> * JFFS3 & locking

I started a locking document for jffs2. Below.

It doesn't follow any style. As I didn't know a decent style for
locking documentation, I made up my own. Feel free to improve it.

Jörn

--
When people work hard for you for a pat on the back, you've got
to give them that pat.
-- Robert Heinlein

Locking hierarchy:

Locks can belong to either an inode or a superblock. "f" is used to
indicate an inode, "c" to indicate a superblock, as in most of the
code:
struct jffs2_inode *f
struct jffs2_sb *c

Each lock in the graph below is requested with all the locks above it
possibly held - as long as their indentation level is less. So
c->inocache_lock can be requested with c->alloc_sem, f->sem and
c->erase_completion_lock held. c->erase_free_sem is never requested
with any other locks held.

none
c->alloc_sem
f->sem
c->erase_completion_lock
c->inocache_lock
c->erase_free_sem
c->gc_thread_start

Protected data structures:

f->sem
everything inside f?

c->alloc_sem
everything in c but the below?

c->erase_completion_lock
c->free_list
c->erasing_list

c->inocache_lock
c->inocache_list

c->erase_free_sem
???

c->gc_thread_start
nothing - just for synchronization