JFFS3 & performance

[Artem B. Bityuckiy]

Some of my comments bellow:

On Fri, 21 Jan 2005, [iso-8859-1] Jörn Engel wrote:
> 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
RULE: Can not have any f->sem locked if gonna lock f->alloc_sem.

> 			c->erase_completion_lock
> 				c->inocache_lock
> 	c->erase_free_sem
> 	c->gc_thread_start
> 
> 
> 
> Protected data structures:
> 
> f->sem
> 	everything inside f?
Yes. Also if you have f->sem seems you may change f->inocache fields 
without having c->inocachelock.

> 
> c->alloc_sem
> 	everything in c but the below?
No. In essence f->alloc_sem protects flash space. Believe this mutex is 
misnamed. And tends to lock code, not data.

> c->erase_completion_lock
Misnamed either. David said this is historical. Protects 
node_ref list.

> 	c->free_list
> 	c->erasing_list
> 
> c->inocache_lock
> 	c->inocache_list
Protects inodcache list. Also protects objects in it. Protects ic->state.

> 
> c->erase_free_sem
> 	???
David hates this. This is to protect node_refs - they are protected by 
both c->erase_complition lock and by c->erase_free_sem. Most time you use 
c->erase_completion lock. But if you need sleep, you use mutex.

> 
> c->gc_thread_start
> 	nothing - just for synchronization


--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.