<div class="gmail_quote">On Mon, May 10, 2010 at 7:37 AM, James Cameron <span dir="ltr"><<a href="mailto:quozl@laptop.org">quozl@laptop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Sat, May 08, 2010 at 05:24:00PM +0000, Tiago Marques wrote:<br>
> I was just looking into this and the issue with SD cards' random write<br>
> performance intrigued me in this particular case.  Isn't recording<br>
> being performed sequentially, hence no lag problem?<br>
<br>
</div>At the moment, assuming an application that opens a file, and writes to<br>
it at _any_ speed, occasionally the write will block for a huge amount<br>
of time.<br>
<br>
As an example, consider this shell script:<br>
<br>
#!/bin/sh<br>
while true; do<br>
        echo ok<br>
        sleep 0.01<br>
done<br>
<br>
And then this command to execute it:<br>
<br>
strace -o /tmp/k -e write -T /tmp/j > /root/file<br>
<br>
And then after several minutes or hours of run the strace file is<br>
analysed:<br>
<br>
grep write k|cut -f2 -d'<'|cut -f1 -d'>'|sort -rn|more<br>
<br>
One will find several instances of write(2) syscalls taking huge<br>
amounts of time:<br>
<br>
0.406725<br>
0.347159<br>
<br>
Now this is surprising given that the I/O rate is trivial, and that<br>
there is ample memory for buffering the writes.<br></blockquote><div><br></div><div>Indeed. But that's the price paid for non-cached 0.04KB/s random write media. I've witnessed some block as much as 2s under heavy I/O.</div>

<div>Also, I've been experimenting with I/O schedulers and they seem to help, although I haven't done any measurement, just using the XO. I should try your test. Someone tested the schedulers and they do make a difference:</div>

<div><br></div><div><a href="http://www.ocztechnologyforum.com/forum/showthread.php?53573-NILFS2-Linux-File-System...-Have-you-tried-it&p=365930&viewfull=1#post365930">http://www.ocztechnologyforum.com/forum/showthread.php?53573-NILFS2-Linux-File-System...-Have-you-tried-it&p=365930&viewfull=1#post365930</a></div>

<div><br></div><div>I only tried noop because deadline is not built in the Fedora XO kernel, but it has been also suggested as an alternative, possibly better than noop:</div><div><br></div><div><div>nilfs scheduler noop 0:15min</div>

<div>nilfs scheduler cfq 0:27min</div><div>btrfs scheduler cfq 0:35min</div><div>ext2 scheduler cfq 1:38min</div><div>ext2 scheduler noop 1:29min</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


<br>
If the test is repeated with the writes directed to tmpfs, there are no<br>
such delays.<br>
<br>
If the test is repeated at a much faster I/O rate using dd(1), ensuring<br>
that ample free memory is available to buffer the writes, then one still<br>
gets huge delays.  Consider this test sequence:<br>
<br>
a.  drop all caches,<br>
<br>
b.  verify free memory,<br>
<br>
c.  write 262144000 bytes in 8192 byte blocks,<br>
<br>
d.  verify cache is used,<br>
<br>
e.  look at the distribution of the slowest writes.<br>
<br>
[root@xo-a7-2a-5a tmp]# echo 1 > /proc/sys/vm/drop_caches<br>
[root@xo-a7-2a-5a tmp]# echo 2 > /proc/sys/vm/drop_caches<br>
[root@xo-a7-2a-5a tmp]# echo 3 > /proc/sys/vm/drop_caches<br>
[root@xo-a7-2a-5a tmp]# free<br>
             total       used       free     shared    buffers     cached<br>
Mem:        949256      96328     852928          0         88      30304<br>
-/+ buffers/cache:      65936     883320<br>
Swap:            0          0          0<br>
[root@xo-a7-2a-5a tmp]# time strace -o /tmp/k -e write -T dd if=/dev/zero of=/root/file bs=8192 count=32000<br>
32000+0 records in<br>
32000+0 records out<br>
262144000 bytes (262 MB) copied, 59.8669 s, 4.4 MB/s<br>
<br>
real    0m59.929s<br>
user    0m1.960s<br>
sys     0m5.350s<br>
[root@xo-a7-2a-5a tmp]# free<br>
             total       used       free     shared    buffers     cached<br>
Mem:        949256     361192     588064          0        672     287568<br>
-/+ buffers/cache:      72952     876304<br>
Swap:            0          0          0<br>
[root@xo-a7-2a-5a tmp]# grep write k|cut -f2 -d'<'|cut -f1 -d'>'|sort -rn|more<br>
11.648413<br>
8.020875<br>
4.299857<br>
3.282466<br>
2.960739<br>
2.151048<br>
2.147674<br>
2.090824<br>
1.972840<br>
1.740923<br>
1.721511<br>
1.674147<br>
1.652831<br>
1.538634<br>
1.430747<br>
1.417739<br>
1.000022<br>
0.961700<br>
0.847079<br>
0.009241<br>
0.009202<br>
0.005332<br>
<br>
I've no explanation for this behaviour.<br>
<br></blockquote><div><br></div><div>hmmm? But this is to the tmpfs???</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I don't think any different filesystem will affect the issue, but it<br>
would probably be a good thing to try.  Let us know how it goes!<br>
<font color="#888888"><br></font></blockquote><div><br></div><div>As you can see by the above tests, there is a good difference, it probably won't mitigate the problem but should make it more bearable. Must recompile some kernels, perhaps I'll have something by the end of the week.</div>

<div><br></div><div>Best regards,</div><div>Tiago</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888">
--<br>
James Cameron<br>
<a href="http://quozl.linux.org.au/" target="_blank">http://quozl.linux.org.au/</a><br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br>
</font></blockquote></div><br>