linux-kernel - Re: [PATCH 00/10] AXFS: Advanced XIP filesystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 12 Sep 2008 14:52:17 -0700
From:	"Jared Hulbert" <jaredeh@...il.com>
To:	"Jamie Lokier" <jamie@...reable.org>
Cc:	"Greg Ungerer" <gerg@...pgear.com>, Linux-kernel@...r.kernel.org,
	linux-embedded@...r.kernel.org,
	linux-mtd <linux-mtd@...ts.infradead.org>,
	"Jörn Engel" <joern@...fs.org>,
	tim.bird@...sony.com, cotte@...ibm.com, nickpiggin@...oo.com.au
Subject: Re: [PATCH 00/10] AXFS: Advanced XIP filesystem

On Fri, Aug 22, 2008 at 11:43 AM, Jamie Lokier <jamie@...reable.org> wrote:
> Jamie Lokier wrote:
>> Jared Hulbert wrote:
>> > What kind of NOR you using?  That is not what I measure with fast
>> > synchronous burst NOR's.
>>
>> I think the "fast" in "fast synchronous" gives it away :-)
>>
>> I'm using Spansion MirrorBit S29GL128N, which reads at about 0.6 MByte/s.
>
> By the way, what speeds do you get on fast synchronous burst NORs - and
> which chips are those?

I am only familiar with the Numonyx product line up.

If you are using a GL, you'll probably find our P33 a good fit and at
competitive prices to GL as I understand it.  That's I think 50Mhz.

M18 is 100Mhz maybe a little higher.  And we just announced our LPDDR
266 part, Velocity LP.

A good way of making a rough estimate of read performance is to
measure a cache miss latency and convert that to bandwidth.  It's
usually fairly close.

32Byte cache size / 16 bit bus = 16 word transfers

memory controller latency (time from Load instruction to bus activity)
= ~300ns (upto 450ns for some processors)
initial latency (time to read first word) = ~100ns (60ns - 120ns)
clock frequency (time between words) = 50Mhz = 20ns per word
bus clean up = ~50ns

32Bytes = 300ns + 100ns + (16 - 1) * 20ns + 50ns = 750ns

= 32B/750ns

= 40MB/s

This is a very simple model and reality is much more nuanced.  You
also need to check my assume numbers with the reality of your system.
Also this doesn't take copying the data to RAM into account which is
usually what you are really measuring.  That's easy to model though.
A rule of thumb is to say that copying to RAM will reduce this value
less than 50% because RAM should be at least a little faster than NOR.

Nevertheless, If you can't use a simple calculation like this to
explain the numbers then you have a poorly configured bus timings or
have your cache off.  Cache is important because it would make the
equation look like this, or worse.

4Bytes = 300ns + 100ns + 1 * 20ns + 50ns = 470ns

=4B/470ns

=8MB/s

For a PXA270 if you go with the defaults it can look like this.

2Bytes = 300ns + 250ns + 250ns = 800ns

= 2MB/s

So, If you are only getting 0.6MB/s out of your NOR..... You're using it wrong.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/