All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: alexlzhu@fb.com
Cc: kernel-team@fb.com, linux-mm@kvack.org, clm@fb.com,
	josef@toxicpanda.com, dsterba@suse.com,
	linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm: fix alginment of VMA for memory mapped files on THP
Date: Tue, 2 Aug 2022 20:06:02 +0200	[thread overview]
Message-ID: <20220802180602.GX13489@twin.jikos.cz> (raw)
In-Reply-To: <20220801184740.2134364-1-alexlzhu@fb.com>

On Mon, Aug 01, 2022 at 11:47:40AM -0700, alexlzhu@fb.com wrote:
> From: alexlzhu <alexlzhu@fb.com>
> 
> With CONFIG_READ_ONLY_THP_FOR_FS, the Linux kernel supports using THPs for
> read-only mmapped files, such as shared libraries. However, the
> kernel makes no attempt to actually align those mappings on 2MB boundaries,
> which makes it impossible to use those THPs most of the time. This issue
> applies to general file mapping THP as well as existing setups using
> CONFIG_READ_ONLY_THP_FOR_FS. This is easily fixed by using
> thp_get_unmapped_area for the unmapped_area function in btrfs, which is
> what ext2, ext4, fuse, and xfs all use.

Commit dbe6ec815641 ("ext2/4, xfs: call thp_get_unmapped_area() for pmd
mappings") adds the callback for DAX, that btrfs does not support so it
was left out.

> The problem can be seen in
> /proc/PID/smaps where THPeligible is set to 0 on mappings to eligible
> shared object files as shown below.
> 
> Before this patch:
> 
> 7fc6a7e18000-7fc6a80cc000 r-xp 00000000 00:1e 199856
> /usr/lib64/libcrypto.so.1.1.1k
> Size:               2768 kB
> THPeligible:    0
> VmFlags: rd ex mr mw me
> 
> With this patch the library is mapped at a 2MB aligned address:
> 
> fbdfe200000-7fbdfe4b4000 r-xp 00000000 00:1e 199856
> /usr/lib64/libcrypto.so.1.1.1k
> Size:               2768 kB
> THPeligible:    1
> VmFlags: rd ex mr mw me
> 
> This fixes the alignment of VMAs for any mmap of a file that has the
> rd and ex permissions and size >= 2MB. The VMA alignment and
> THPeligible field for anonymous memory is handled separately and
> is thus not effected by this change.
> 
> Signed-off-by: alexlzhu <alexlzhu@fb.com>

Please use full name for signed-off.

Also the subject should start with "btrfs:", this is not a memory
management patch. Thanks.

  reply	other threads:[~2022-08-02 18:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-01 18:47 [PATCH v2] mm: fix alginment of VMA for memory mapped files on THP alexlzhu
2022-08-02 18:06 ` David Sterba [this message]
2022-08-02 19:36   ` Alex Zhu (Kernel)

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=20220802180602.GX13489@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=alexlzhu@fb.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=josef@toxicpanda.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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 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.