Re: Page Cache writeback too slow, SSD/noop scheduler/ext2

[Jos Houtman]

Hi,

>> 
>> kupdate surely should just continue to keep trying to write back pages
>> so long as there are more old pages to clean, and the queue isn't
>> congested. That seems to be the intention anyway: MAX_WRITEBACK_PAGES
>> is just the number to write back in a single call, but you see
>> nr_to_write is set to the number of dirty pages in the system.

And when it's congested it should just wait a little bit before continuing.
 
>> On your system, what must be happening is more_io is not being set.
>> The logic in fs/fs-writeback.c might be busted.

I don't know about more_io, but I agree that the logic seems busted.

> 
> Hi Jos,
> 
> I prepared a debugging patch for 2.6.28. (I cannot observe writeback
> problems on my local ext2 mount.)

Thanx for the patch, but for the next time: How should I apply it?
it seems to be context aware (@@) and broke on all kernel versions I tried
2.6.28/2.6.28.7/2.6.29

Because I saw the patch only a few hour ago and didn't want to block on your
reply I decided to patch it manually and in the process ported it to 2.6.29.

As for the information the patch provided: It is most helpful.

Attached you will find a list of files containing dirty pages and the count
of there dirty pages, there is also a dmesg output where I trace the
writeback for 40 seconds.


I did some testing on my own using printk's and what I saw is that for the
inodes located on sdb1 (the database) a lot of times they would pass
http://lxr.linux.no/linux+v2.6.29/fs/fs-writeback.c#L335
And then redirty_tail would be called, I haven't had the time to dig deeper,
but that is my primary suspect for the moment.


Thanx again, 

Jos

Attachment: filecache-27-march.txt
Description: Binary data

Attachment: dmesg-27-march.txt
Description: Binary data