Re: JFFS3 & performance

Artem B. Bityuckiy
2005-01-21T14:04:31Z

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.