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