Re: [LSF/MM TOPIC] Writeback - current state and future

[Boaz Harrosh <bharrosh@panasas.com>]

On 02/04/2011 06:42 PM, Jan Kara wrote:
>   Hi,
> 
>   I'd like to have one session about writeback. The content would highly
> depend on the current state of things but on a general level, I'd like to
> quickly sum up what went into the kernel (or is mostly ready to go) since
> last LSF (handling of background writeback, livelock avoidance), what is
> being worked on - IO-less balance_dirty_pages() (if it won't be in the
> mostly done section), what other things need to be improved (kswapd
> writeout, writeback_inodes_sb_if_idle() mess, come to my mind now)
> 
> 								Honza

Ha, I most certainly want to participate in this talk. I wanted to
suggest it myself.

Topics that I would like to raise on the matter.

[IO-less balance_dirty_pages]
As said, I'd really like if Wu or Jan could explain more about the math
and IO patterns that went into this tremendous work, and how it should
affect us fs maintainers in means of advantages and disadvantages. If
digging too deeply into this is not interesting for every body, perhaps
a side meeting with fewer people is also possible.

[Aligned write-back]
I have just finished raid5/6 support in my filesystem and will be sending
a patch that tries very aggressively to align IO on stripe boundaries.
I did not take the btrfs way of cut/paste of the write_cache_pages() function
to better fit the bill. I used the wbc->nr_to_write to trim down IO on stripe
alignment. Together with some internal structure games, I now have a much
better situation then untouched code. Better I mean that if I have simple
linear dd IO on a file, I can see o(90%) aligned IOs as opposed to 20% before
that patch. The only remaining issue, I think I have not fully investigated
it yet, is that: because I do not want any residues left from outside the
writepages() call so I do not need to sync and lock with flush, and have a
"flushing" flag in my writeout path. So what I still get is that sometimes
the writeback is able to catch up with dd and I get short writes at the
reminder, which makes the end of this call and the start of the next call
unaligned.

I envision a simple BDI members just like ra_pages for readahead that better
govern the writeback chunking. (And is accounted for in the fairness).

[Smarter/more cache eviction patterns]
I love it when I do a simple dd test in a UML (300Mg of ram) and half way down
I get these fat WARN_ONs of the iscsi tcp writeback failing to allocate network
buffers. And I did lower the writeback ratio a lot because the default of 20% does
not work for a long time, like since 35 or 36. The UML is not the only affected
system any low-memory embedded-like but 64 bit system would be. Now the IO does
complete eventually but the performance is down to 20%.

Now for a dd or cp like work pattern I would like the pages be freed much more
aggressively, like right after IO completion because I most certainly will not
use them again. On the other side git for example will write a big sequential
file then immediately turn and read it, so cache presence is a win. But I think
we can still come up with good patterns that take into account the number of
fileh opened on an inode, and some hot inode history to come up with better
patterns. (Some of this history we already have with the security plugins)

And there are other topics that I had, but can remember right now.

Thanks
Boaz