On Wednesday 03 February 2010 23:17:42 Johan Kotlinski wrote: > Hi Charles! > > Thanks for your answer. Yes, I was talking about yaffs direct. Page-by-page > locking is of course all right. > > I have another question. Our NAND chip has the ability to prefetch pages. I > imagine we could benefit from this. Is there a way to get a hint from yaffs > what it is about to read next? Or do you know some good place to insert > such an optimization? > > Best regards, > Johan > I have just checked in code which breaks up long reads and writes into smaller sub read/writes. This has the advantage of reducing longing times. Please give this a whirl if it is of interest to you. -- Charles > ----- Original Message ----- > From: "Charles Manning" > To: > Cc: "Johan Kotlinski" > Sent: Wednesday, February 03, 2010 1:15 AM > Subject: Re: [Yaffs] multithreading question > > > On Tuesday 02 February 2010 00:29:17 Johan Kotlinski wrote: > >> Hi! > >> It appears that Yaffs2 multithreading protection is on a very high level > >> (mutex wrapping entire fread/fwrite calls). > > > > Are you talking about yaffs direct or the Linux yaffs? > > The linux yaffs will be locked on a page-by-page basis and I am going to > > change the way yaffs direct does the reading/writing too to only lock on > > a page-by-page basis. > > > > The underlying NAND is locked on a apge by page basis too (that's a > > limitation > > of the hardware), so is this really a big concern? > > > >> My worry is that if a low-priority task does a large fwrite call, it > >> could > >> block high-priority tasks for a long time. Is this an acknowledged > >> problem? > > > > It depends on the OS. Some, without priority inhere, won't have this > > problem. > > > >> Are there comparable file systems that handle multithreading in a more > >> granular way? > > _______________________________________________ > yaffs mailing list > yaffs@lists.aleph1.co.uk > http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs