Tested the flusher slightly
Daniel Phillips
daniel.raymond.phillips at gmail.com
Mon Jun 24 09:02:34 PDT 2013
99% of blockdev of blockdev speed sounds like something to be proud
of. What is media speed, as measured by hdparm -t?
On Mon, Jun 24, 2013 at 5:34 AM, OGAWA Hirofumi
<hirofumi at mail.parknet.co.jp> wrote:
> Daniel Phillips <daniel.raymond.phillips at gmail.com> writes:
>
>>> And FLUSH command makes slower slightly. blocksize 512 makes slower, and
>>> increase cpu systime, because probably buffer_head overhead, especially
>>> sort of buffer_head (perf says buffer_index_cmp() is top cpu user).
>>
>> The performance results for this load seem more than satisfactory. The
>> superblock commit strategy shows up a only a small part of the cost
>> for this load, unsurprisingly, but is probably a much bigger part of
>> some other loads, for example a series of small writes, each followed
>> by sync.
>
> I was forgetting to measure blockdev (this would be basically best for
> this load).
>
> [blockdev]
> 4294967296 bytes (4.3 GB) copied, 63.138 s, 68.0 MB/s
>
> real 1m3.346s
> user 0m0.280s
> sys 0m5.484s
>
>
> tux3 is now 67.2 MB/s, I feel this path can be optimize more (we have
> overhead of metadata though, but...). Well, anyway, above one would be
> one of goals.
>
> [To measure blockdev, I have to do some sort of tricky way. Because
> blockdev seems to initialize the blocksize for each initial open.
>
> # sleep 3600 < /dev/sdb2 &
> # blockdev --setbsz 4096 /dev/sdb2
> # time dd if=/dev/zero of=/dev/sdb2 bs=4K count=1M
> ]
> --
> OGAWA Hirofumi <hirofumi at mail.parknet.co.jp>
More information about the Tux3
mailing list