Re: [PATCH v2 12/12] mm/filemap: Return only head pages from find_get_entries

[Matthew Wilcox]

On Thu, Oct 01, 2020 at 09:17:28AM +0200, Jan Kara wrote:
> > I have a followup patch which isn't part of this series which fixes it:
> > 
> > http://git.infradead.org/users/willy/pagecache.git/commitdiff/364283163847d1c106463223b858308c730592a1
> 
> Yeah, that looks good. How about partial THPs? The way you've implemented
> it we will now possibly evict more than strictly required. But OTOH
> evicting exactly may require THP split which is a bit unfortunate. But
> probably still a better option because otherwise we could have pages being
> repeatedly brought in and out of cache just because e.g. workload mixes
> direct and buffered IO and is not aligned to THP boundary (and although I
> find loads mixing buffered and direct IO to the same file badly designed,
> I know for a fact that they do exist and if the file ranges are not
> overlapping, it is not that insane design).

Sorry, forgot to reply to this.

In this patchset, THPs are created by readahead.  We always start
out by allocating order-0 pages and only ramp up after hitting a page
marked as PageReadahead.  So it's not like tmpfs where we'll try to jump
straight to order-9 pages and have to worry about the behaviour you're
describing above.  That means in this kind of scenario, we might have,
eg, an order-6 page in the cache, remove the whole thing, then bring
back in some order-0 pages.  If we hit on those, we'll bring in some
order-2 pages.  We won't bring in order-6 pages again until we've hit
in the readahead window twice more.

I think the ramp-up is probably too aggressive, but it's fun for testing.