Re: Bug#605009: serious performance regression with ext4
Ted Ts'o wrote:
> On Mon, Nov 29, 2010 at 02:16:02PM +0100, Raphael Hertzog wrote:
>> It means we don't need to keep it in RAM since we're not going to
>> read/modifiy it again in the near future. Thus the writeback can be
>> started right now since delaying it will not save us anything.
>>
>> At least that's the way I understand the situation.
>
> Yes, that's correct. The fadvise() will do two things; it will start
> the writeback, and also make these memory pages be the most likely to
> be discarded.
That explanation helps a lot. Thanks, both. (Guillem, I like your
patch very much then. Most files being unpacked in a dpkg run aren't
going to be read back again soon. Perhaps some other kernels will
also interpret it as a hint to start writeback.)
> The reason why I suggested using sync_file_range() is because it is
> very specifically directed at forcing the writeback to happen, which
> is not quite the same thrust as posix_fadvise().
I suppose a patch to adopt the optimization you suggested ought to
also do the sync_file_range() directly to be explicit.
Reply to: