[PATCH] cafe_nand: remove busy-wait loop

Daniel Drake dsd at laptop.org
Tue Dec 9 15:15:55 EST 2008


On Tue, Dec 9, 2008 at 5:05 PM, Mitch Bradley <wmb at laptop.org> 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 fraction of
> the real time.

The system time does drop considerably, but unfortunately the transfer
rate also decreases significantly. I think this is because many of the
commands execute very quickly (1-10us), therefore it is wasteful to go
and schedule a new process only to come back immediately after.
Perhaps we can come up with a scheme that does a fast busy-loop for
the quick commands, and then schedules for the longer ones.

Here are the results anyway. Both experiments running on joyride-2579,
jffs2 filesystem, and a 50mb "randfile" that I generated on another
computer from /dev/urandom

First experiment was "echo 3 > /proc/sys/vm/drop_caches; time dd
if=randfile of=/dev/null"
that is, reading the file from the NAND, with caches cold. Repeated 3 times.

Before:
52428800 bytes (52 MB) copied, 5.4499 s, 9.6 MB/s
real	0m7.324s
sys	0m7.080s

52428800 bytes (52 MB) copied, 5.38514 s, 9.7 MB/s
real	0m5.452s
sys	0m5.190s

52428800 bytes (52 MB) copied, 5.41167 s, 9.7 MB/s
real	0m5.480s
sys	0m5.210s



After:
52428800 bytes (52 MB) copied, 10.2002 s, 5.1 MB/s
real	0m24.593s
sys	0m2.310s

52428800 bytes (52 MB) copied, 10.166 s, 5.2 MB/s
real	0m10.266s
sys	0m0.910s

52428800 bytes (52 MB) copied, 9.72464 s, 5.4 MB/s
real	0m9.840s
sys	0m1.210s

So, the transfer rate dropped from about 9.6mb/sec to about 5.3mb/sec.
However, sys time decreased by a factor of about 5. Also note that the
first run in each case took significantly longer (especially in the
after case, perhaps an anomaly) presumably because it had to load 'dd'
from nand too.



Second experiment: duplicate the file on disk, with hot caches so that
we are measuring write (and not also read).
"rm copy; cat randfile > /dev/null; time cp randfile copy" repeated 3 times

Before:
real	0m56.459s
sys	0m51.280s

real	0m57.919s
sys	0m51.300s

real	0m56.016s
sys	0m50.970s

After:
real	1m36.600s
sys	0m7.480s

real	1m19.303s
sys	0m6.980s

real	1m28.450s
sys	0m6.930s


Again, a considerable increase in real time, and a considerable
decrease in sys time.

I'll try and find some time to identify which commands are the ones
that take long, and then try a patch that only avoids the busy-wait
for those ones.

Daniel



More information about the Devel mailing list