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
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
> 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 m
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
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
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
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
th
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,
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
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 interrup
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
11 matches
Mail list logo
