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
| ||
|
Date: Sun, 25 Oct 2020 23:19:34 +0000 From: Matthew Wilcox <willy@...radead.org> To: Jan Kara <jack@...e.cz> Cc: 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 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.
Powered by blists - more mailing lists