linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: William Kucharski <william.kucharski@oracle.com>
To: Song Liu <liu.song.a23@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	Keith Busch <keith.busch@intel.com>,
	Linux-MM <linux-mm@kvack.org>,
	Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-nvme@lists.infradead.org, linux-block@vger.kernel.org
Subject: Re: Read-only Mapping of Program Text using Large THP Pages
Date: Tue, 30 Apr 2019 06:12:04 -0600	[thread overview]
Message-ID: <C39B5A6C-2898-44DC-B11B-017908261C09@oracle.com> (raw)
In-Reply-To: <CAPhsuW6uDeXrRU9pd-kPOzjJn3DVdx0O5Lny_hpyQ=Fpbhg4gw@mail.gmail.com>



> On Apr 28, 2019, at 2:08 PM, Song Liu <liu.song.a23@gmail.com> wrote:
> 
> We will bring this proposal up in THP discussions. Would you like to share more
> thoughts on pros and cons of the two solutions? Or in other words, do you have
> strong reasons to dislike either of them?

I think it's a performance issue that needs to be hashed out.

The obvious thing to do is read the whole large page and then map
it, but depending on the architecture or I/O speed, mapping one
PAGESIZE page to satisfy the single fault while the large page is
being read in could potentially be faster. However, as with all
swags without actual data who can say. You can also bring up the
question of whether with SSDs and NVME storage if it makes sense
to worry anymore about how long it would take to read a 2M or even
1G page in from storage. I like the idea of simply reading the
entire large page purely for neatness reasons - recovering from an
error during redhead of a large page seems like it could become
rather complex.

One other issue is how this will interact with filesystems and how
and how to tell filesystems I want a large page's worth of data.
Matthew mentioned that compound_order() can be used to detect the
page size, so that's one answer, but obviously no such code exists
as of yet and it would need to be propagated across all file systems.

I really hope the discussions at LSFMM are productive.

-- Bill

      reply	other threads:[~2019-04-30 12:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-20 11:17 [LSF/MM TOPIC ][LSF/MM ATTEND] Read-only Mapping of Program Text using Large THP Pages William Kucharski
2019-02-20 12:10 ` Michal Hocko
2019-02-20 13:18   ` William Kucharski
2019-02-20 13:27     ` Michal Hocko
2019-02-20 13:44 ` Matthew Wilcox
2019-02-20 14:07   ` William Kucharski
2019-02-20 14:43     ` Matthew Wilcox
2019-02-20 16:39       ` Keith Busch
2019-02-20 17:19         ` Matthew Wilcox
2019-04-08 11:36           ` William Kucharski
2019-04-28 20:08             ` Song Liu
2019-04-30 12:12               ` William Kucharski [this message]

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=C39B5A6C-2898-44DC-B11B-017908261C09@oracle.com \
    --to=william.kucharski@oracle.com \
    --cc=keith.busch@intel.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=liu.song.a23@gmail.com \
    --cc=willy@infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).