Re: Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB

[Nick Piggin <nickpiggin@yahoo.com.au>]

On Friday 30 January 2009 12:23:15 Jan Kara wrote:
>   Hi,
>
>   today I found that commit 31a12666d8f0c22235297e1c1575f82061480029 (mm:
> write_cache_pages cyclic fix) slows down operations over Berkeley DB.
> Without this "fix", I can add 100k entries in about 5 minutes 30s, with
> that change it takes about 20 minutes.
>   What is IMO happening is that previously we scanned to the end of file,
> we left writeback_index at the end of file and went to write next file.
> With the fix, we wrap around (seek) and after writing some more we go
> to next file (seek again).

Hmm, but isn't that what pdflush has asked for? It is wanting to flush
some of the dirty data out of this file, and hence it wants to start
from where it last flushed out and then cycle back and flush more?


>   Anyway, I think the original semantics of "cyclic" makes more sence, just
> the name was chosen poorly. What we should do is really scan to the end of
> file, reset index to start from the beginning next time and go for the next
> file.

Well, if we think of a file as containing a set of dirty pages (as it
appears to the high level mm), rather than a sequence, then behaviour
of my patch is correct (ie. there should be no distinction between dirty
pages at different offsets in the file).

However, clearly there is some problem with that assumption if you're
seeing a 4x slowdown :P I'd really like to know how it messes up the IO
patterns. How many files in the BDB workload? Are filesystem blocks
being allocated at the end of the file while writeout is happening?
Delayed allocation?


>   I can write a patch to introduce this semantics but I'd like to hear
> opinions of other people before I do so.

I like dirty page cleaning to be offset agnostic as far as possible,
but I can't argue with numbers like that. Though maybe it would be
possible to solve it some other way.