linux-kernel - Re: [PATCH v4 00/36] Large pages in the page cache

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200526012141.GE17206@bombadil.infradead.org>
Date:   Mon, 25 May 2020 18:21:41 -0700
From:   Matthew Wilcox <willy@...radead.org>
To:     Dave Chinner <david@...morbit.com>
Cc:     linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 00/36] Large pages in the page cache

On Tue, May 26, 2020 at 09:07:51AM +1000, Dave Chinner wrote:
> On Thu, May 21, 2020 at 08:05:53PM -0700, Matthew Wilcox wrote:
> > On Fri, May 22, 2020 at 12:57:51PM +1000, Dave Chinner wrote:
> > > Again, why is this dependent on THP? We can allocate compound pages
> > > without using THP, so why only allow the page cache to use larger
> > > pages when THP is configured?
> > 
> > We have too many CONFIG options.  My brain can't cope with adding
> > CONFIG_LARGE_PAGES because then we might have neither THP nor LP, LP and
> > not THP, THP and not LP or both THP and LP.  And of course HUGETLBFS,
> > which has its own special set of issues that one has to think about when
> > dealing with the page cache.
> 
> That sounds like something that should be fixed. :/

If I have to fix hugetlbfs before doing large pages in the page cache,
we'll be five years away and at least two mental breakdowns.  Honestly,
I'd rather work on almost anything else.  Some of the work I'm doing
will help make hugetlbfs more similar to everything else, eventually,
but ... no, not going to put all this on hold to fix hugetlbfs.  Sorry.

> Really, I don't care about the historical mechanisms that people can
> configure large pages with. If the mm subsystem does not have a
> unified abstraction and API for working with large pages, then that
> is the first problem that needs to be addressed before other
> subsystems start trying to use large pages. 

I think you're reading too quickly.  Let me try again.

Historically, Transparent Huge Pages have been PMD sized.  They have also
had a complicated interface to use.  I am changing both those things;
THPs may now be arbitrary order, and I'm adding interfaces to make THPs
easier to work with.

Now, if you want to contend that THPs are inextricably linked with
PMD sizes and I need to choose a different name, I've been thinking
about other options a bit.  One would be 'lpage' for 'large page'.
Another would be 'mop' for 'multi-order page'.

We should not be seeing 'compound_order' in any filesystem code.
Compound pages are an mm concept.  They happen to be how THPs are
implemented, but it'd be a layering violation to use them directly.