linux-kernel - Re: [PATCH v2 12/12] mm/filemap: Return only head pages from find_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 26 Oct 2020 10:11:55 +0100
From:   Jan Kara <jack@...e.cz>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Jan Kara <jack@...e.cz>, linux-mm@...ck.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Hugh Dickins <hughd@...gle.com>,
        William Kucharski <william.kucharski@...cle.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Yang Shi <yang.shi@...ux.alibaba.com>,
        Dave Chinner <dchinner@...hat.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 12/12] mm/filemap: Return only head pages from
 find_get_entries

On Sun 25-10-20 23:19:34, Matthew Wilcox wrote:
> 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.

OK, sounds good then. Thanks for explanation.

								Honza

-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR