Re: [Yaffs] Re: performans off YAFFS1 on NOR flash

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Charles Manning
Date:  
To: yaffs
CC: Peter Barada
Subject: Re: [Yaffs] Re: performans off YAFFS1 on NOR flash
On Saturday 15 October 2005 07:32, Peter Barada wrote:

>
> I'm not sure about POSIX, but using raw 'down' is frowned upon in the
> kernel since you can end up with processes that take quite a while to
> respond to signals(if at all) since the 'down' is not interruptible.
>
> If I change the lock to use down_interruptible, where in yaffs_fs.c do I
> have to be *very* careful about exitting with an -ERESTARTSYS?


Yes, this is the bit that makes me antsy!

> Actually I've modified the lock/unlock code to be:
>
> atomic_t n_locksRequested = ATOMIC_INIT(0);
> atomic_t n_locksGranted = ATOMIC_INIT(0);
> static unsigned long maxJiffies;
> atomic_t sumLockTime = ATOMIC_INIT(0);
> atomic_t sumLockTimeSquared = ATOMIC_INIT(0);
>
> static void yaffs_GrossLock(yaffs_Device *dev)
> {
>     unsigned long reqJiffies, diffJiffies;
>     T(YAFFS_TRACE_OS,("yaffs locking\n"));

>
>     atomic_inc(&n_locksRequested);
>     reqJiffies = jiffies;
>     down(&dev->grossLock);
>     atomic_inc(&n_locksGranted);
>     diffJiffies = jiffies - reqJiffies;
>     if (diffJiffies > maxJiffies) {
>       maxJiffies = diffJiffies;
>       printk("%s: wait %lu for lock\n", __FUNCTION__, maxJiffies);
>     }
>     atomic_add(diffJiffies, &sumLockTime);
>     atomic_add(diffJiffies*diffJiffies, &sumLockTimeSquared);
> }

>
> static void yaffs_GrossUnlock(yaffs_Device *dev)
> {
>     int yieldToRequestor;
>     T(YAFFS_TRACE_OS,("yaffs unlocking\n"));

>
>     yieldToRequestor = atomic_read(&n_locksGranted) - atomic_read
> (&n_locksRequested);
>     up(&dev->grossLock);
>     if (yieldToRequestor)
>         yield();

>
> }
>
>
> Which sees if on an up() if another thread is waiting, and if so, then
> it executes 'yield()' to give the other thread a chance to get in. This
> works much better for two processes trying to access the same YAFFS.


It would seem that the above is a fair thing to do if it improves things for
you.

As previously mentioned, this is not my area of expertise. I just copied
something out of jffs2 or Linux Device Drivers a few years back. I would
appreciate the opinions of anyone with better knowledge.

I don't know if this is something that everyone would always want, so perhaps
this could be conditional code.


> I
> haven't instrumented JFFS/2, but I have a feeling that the asynch
> garbage collection would give better numbers.


My hunch too is that this would give the biggest payback. It would at least
get rid of the outliers (waiting for erase).


> > > 2) Is there anyway to more finely lock YAFFS instead of the gross lock
> > > that exists now?
> > > 3) How can yaffs_file_flush take *so* long is nShortOpCache is set to
> > > zero so yaffs_FlushFilesChunkCache should take no time?
> >
> > Agreed. That does seem rather bizarre. Did the real-world time match the
> > instrumenting?
>
> Yes.


Did these improve with the new yield stuff?

-- CHarles