From: Matthew Wilcox <willy@infradead.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: William Kucharski <william.kucharski@oracle.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
Song Liu <songliubraving@fb.com>,
Bob Kasten <robert.a.kasten@intel.com>,
Mike Kravetz <mike.kravetz@oracle.com>,
Chad Mynhier <chad.mynhier@oracle.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Johannes Weiner <jweiner@fb.com>
Subject: Re: [PATCH v5 2/2] mm,thp: Add experimental config option RO_EXEC_FILEMAP_HUGE_FAULT_THP
Date: Tue, 3 Sep 2019 05:22:08 -0700 [thread overview]
Message-ID: <20190903122208.GE29434@bombadil.infradead.org> (raw)
In-Reply-To: <20190903121424.GT14028@dhcp22.suse.cz>
On Tue, Sep 03, 2019 at 02:14:24PM +0200, Michal Hocko wrote:
> On Mon 02-09-19 03:23:41, William Kucharski wrote:
> > Add filemap_huge_fault() to attempt to satisfy page
> > faults on memory-mapped read-only text pages using THP when possible.
>
> This deserves much more description of how the thing is implemented and
> expected to work. For one thing it is not really clear to me why you
> need CONFIG_RO_EXEC_FILEMAP_HUGE_FAULT_THP at all. You need a support
> from the filesystem anyway. So who is going to enable/disable this
> config?
There are definitely situations in which enabling this code will crash
the kernel. But we want to get filesystems to a point where they can
start working on their support for large pages. So our workaround is
to try to get the core pieces merged under a CONFIG_I_KNOW_WHAT_IM_DOING
flag and let people play with it. Then continue to work on the core
to eliminate those places that are broken.
> I cannot really comment on fs specific parts but filemap_huge_fault
> sounds convoluted so much I cannot wrap my head around it. One thing
> stand out though. The generic filemap_huge_fault depends on ->readpage
> doing the right thing which sounds quite questionable to me. If nothing
> else I would expect ->readpages to do the job.
Ah, that's because you're not a filesystem person ;-) ->readpages is
really ->readahead. It's a crappy interface and should be completely
redesigned.
Thanks for looking!
next prev parent reply other threads:[~2019-09-03 12:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-02 9:23 [PATCH v5 0/2] mm,thp: Add filemap_huge_fault() for THP William Kucharski
2019-09-02 9:23 ` [PATCH v5 1/2] mm: Allow the page cache to allocate large pages William Kucharski
2019-09-03 11:57 ` Michal Hocko
2019-09-03 12:11 ` Matthew Wilcox
2019-09-03 12:19 ` Michal Hocko
2019-09-03 16:28 ` Matthew Wilcox
2019-09-03 19:18 ` Michal Hocko
2019-09-04 3:30 ` William Kucharski
2019-09-04 8:28 ` Michal Hocko
2019-09-02 9:23 ` [PATCH v5 2/2] mm,thp: Add experimental config option RO_EXEC_FILEMAP_HUGE_FAULT_THP William Kucharski
2019-09-03 12:14 ` Michal Hocko
2019-09-03 12:22 ` Matthew Wilcox [this message]
2019-09-03 12:51 ` Michal Hocko
2019-09-03 15:10 ` Matthew Wilcox
2019-09-03 19:15 ` Michal Hocko
2019-09-04 3:23 ` William Kucharski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190903122208.GE29434@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=chad.mynhier@oracle.com \
--cc=dave.hansen@linux.intel.com \
--cc=jweiner@fb.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mike.kravetz@oracle.com \
--cc=robert.a.kasten@intel.com \
--cc=songliubraving@fb.com \
--cc=william.kucharski@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.