So, the transfer rate dropped from about 9.6mb/sec to about 5.3mb/sec.
I was afraid of this. Flash is pretty fast, and there's almost no
parallelism available in it (e.g. you can't queue up a bunch of reads
to occur when the data rotates under the heads, or start a seek
early). Thus it's
Hi John,
It's unfortunate that there's no block device way to access Flash
chips in Linux without using a filesystem at all. It's much easier
to measure and tune I/O performance without a filesystem first,
then see what (filesystem or driver) optimizations are required to
On Wed, 2008-12-10 at 15:36 -0500, Chris Ball wrote:
Hi John,
It's unfortunate that there's no block device way to access Flash
chips in Linux without using a filesystem at all. It's much easier
to measure and tune I/O performance without a filesystem first,
then see what
This patch enables interrupts for DMA and command completion events, and
uses them to determine when commands and transfers have completed.
This avoids a busy-wait loop which was a waste of CPU time.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
---
Where do we go with this? Who's adventurous
Nice!
One quick test, for starters, is to do some file accesses to large files
(dd or tar or whatever) and use the time command to look at the system
and user times. With the patch, the system time should drop to a
fraction of the real time.
Daniel Drake wrote:
This patch enables interrupts
On Tue, Dec 9, 2008 at 6:05 PM, Mitch Bradley [EMAIL PROTECTED] wrote:
Nice!
One quick test, for starters, is to do some file accesses to large files
(dd or tar or whatever) and use the time command to look at the system
and user times. With the patch, the system time should drop to a
Tomeu Vizoso wrote:
On Tue, Dec 9, 2008 at 6:05 PM, Mitch Bradley [EMAIL PROTECTED] wrote:
Nice!
One quick test, for starters, is to do some file accesses to large files
(dd or tar or whatever) and use the time command to look at the system
and user times. With the patch, the system
On Tue, 2008-12-09 at 07:05 -1000, Mitch Bradley wrote:
Where do we go with this? Who's adventurous enough to test it? Dare we
put it in joyride? Any suggestions for how to measure performance
difference?
If Deepak likes it and it passes some tests, that would be the logical
thing to
And then Mitch tosses the next ball to Daniel to catch.
On 12/9/08 12:22 PM, Jim Gettys [EMAIL PROTECTED] wrote:
On Tue, 2008-12-09 at 07:05 -1000, Mitch Bradley wrote:
Where do we go with this? Who's adventurous enough to test it? Dare we
put it in joyride? Any suggestions for how to
On Dec 09 2008, at 16:05, Daniel Drake was caught saying:
This patch enables interrupts for DMA and command completion events, and
uses them to determine when commands and transfers have completed.
This avoids a busy-wait loop which was a waste of CPU time.
Signed-off-by: Daniel Drake
On Tue, Dec 9, 2008 at 5:05 PM, Mitch Bradley [EMAIL PROTECTED] wrote:
Nice!
One quick test, for starters, is to do some file accesses to large files (dd
or tar or whatever) and use the time command to look at the system and
user times. With the patch, the system time should drop to a
11 matches
Mail list logo
