Tested the flusher slightly

[Daniel Phillips]

On Sun, Jun 23, 2013 at 8:54 AM, OGAWA Hirofumi
<hirofumi at mail.parknet.co.jp> wrote:
> I've tested the flusher slightly to see some tweak has any difference. ...
> As expected, for now, tux3 is slightly faster than ext4. Maybe, because
> we are using the write-optimized block allocation(?).

I think that this apparent efficiency advantage over Ext4 is due to
something else, because "allocate next" is the correct allocation
strategy for this load.  We do need to take care that the upcoming
layout optimization work does not change this behaviour in any
significant way. Using a cheap test, we should ensure that no
heuristic fancier than "allocate next" is even evaluated while this
simple load continues. An example of such a cheap test might be: the
delta consists entirely of a linear write to the same inode as the
previous delta, therefore just continue.

Such a simple test will be easy to fool. For example there might be
tiny amount of parallel IO. So we will need to improve this "short
circuit" evaluation over time to cover more cases, in the interest of
evaluating our heuristcs efficiently. In general, our heuristics can
be summed up as: "do we continue allocating from where we allocated
last or do we search for a new allocation goal?"

> 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.

Regards,

Daniel