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
(text/plain)