Longs spinlock on NOR reads

[Roger Lucas]

Hi Bill,

Firstly, many apologies that it has taken me so long to provide the patch...
It is very small but I have had so many other things on, I just didn't get
around to it.

The patch only applies to the one FLASH chip that we have one the system we
are using.  I'm sure something similar may be appropriate for the other
chips but I don't want to offer a patch against something that I haven't
tried and cannot test.

Best regards,

Roger

-----Original Message-----
From: Bill Gatliff [mailto:bgat at billgatliff.com] 
Sent: 26 June 2009 00:21
To: Roger Lucas
Cc: linux-mtd at lists.infradead.org
Subject: Re: Longs spinlock on NOR reads

Roger Lucas wrote:
> Before going through the process of submitting patches etc., is this a 
> problem that has been identified or experienced before?  I have searched
the
> mailing list but not seen any obvious references...
>   

I haven't seen the problem you are describing, but I haven't studied the
performance of JFFS2 down at those time levels.  Your problem
description sounds very reasonable, however, as does the proposed fix.

I think you'll probably get down to 7ms only if the compiler is doing a
lot of ldm/stm, which I'd be surprised to see.  But the overhead of a
function call for every 512 bytes might be measurable--- is there a
point within the lowest-level code that might be a good place to briefly
unlock and then re-lock the spinlock?  That would reduce the overhead of
the fix by avoiding the function call.

Regardless, if someone is paying attention to the numbers then they're
probably more concerned with the latency than throughput.  In that case,
if the only way to substantially improve latency is to take a
per-512-byte function call hit then I (for one) can live with that.

> If it seems a reasonable observation and fix, would you like me to post a 
> patch?  I can only patch and test the 'cfi_cmdset_0002.c' driver but it 
> would be a simple process for it to be applied to the other chips.
>   

Definitely post the patch.  Can't reject something we haven't seen.  :)

Maybe it needs to be surrounded by a CONFIG_MTD_<something> so that
people can turn it on or off via menuconfig.


b.g.

Checked by AVG - www.avg.com 
Version: 8.5.375 / Virus Database: 270.12.92/2202 - Release Date: 06/25/09
17:58:00
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfi_cmdset_0002.c.diff
Type: application/octet-stream
Size: 1422 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20090809/492c0c1c/attachment.obj>