JFFS3 & performance

[Jörn Engel]

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