diff mbox series

mm: align larger anonymous mappings on THP boundaries

Message ID 20220808164658.5079a9a0@imladris.surriel.com (mailing list archive)
State New
Headers show
Series mm: align larger anonymous mappings on THP boundaries | expand

Commit Message

Rik van Riel Aug. 8, 2022, 8:46 p.m. UTC
Align larger anonymous memory mappings on THP boundaries by
going through thp_get_unmapped_area if THPs are enabled for
the current process.

With this patch, larger anonymous mappings are now THP aligned
when checking in /proc/PID/maps, but only when THP is enabled
for that process.

Signed-off-by: Rik van Riel <riel@surriel.com>
---
 mm/mmap.c | 3 +++
 1 file changed, 3 insertions(+)

Comments

Andrew Morton Aug. 8, 2022, 10:09 p.m. UTC | #1
On Mon, 8 Aug 2022 16:46:58 -0400 Rik van Riel <riel@surriel.com> wrote:

> Align larger anonymous memory mappings on THP boundaries by
> going through thp_get_unmapped_area if THPs are enabled for
> the current process.
> 
> With this patch, larger anonymous mappings are now THP aligned
> when checking in /proc/PID/maps, but only when THP is enabled
> for that process.
> 

What are the runtime effects of this change?
Rik van Riel Aug. 9, 2022, 12:59 a.m. UTC | #2
On Mon, 2022-08-08 at 15:09 -0700, Andrew Morton wrote:
> On Mon, 8 Aug 2022 16:46:58 -0400 Rik van Riel <riel@surriel.com>
> wrote:
> 
> > Align larger anonymous memory mappings on THP boundaries by
> > going through thp_get_unmapped_area if THPs are enabled for
> > the current process.
> > 
> > With this patch, larger anonymous mappings are now THP aligned
> > when checking in /proc/PID/maps, but only when THP is enabled
> > for that process.
> > 
> 
> What are the runtime effects of this change?

The runtime effect is that when a malloc library
allocates an arena that is a multiple of 2MB in size,
the entire arena can be mapped using THPs, resulting in
a lower TLB miss rate.
Yang Shi Aug. 9, 2022, 5:16 p.m. UTC | #3
On Mon, Aug 8, 2022 at 1:47 PM Rik van Riel <riel@surriel.com> wrote:
>
> Align larger anonymous memory mappings on THP boundaries by
> going through thp_get_unmapped_area if THPs are enabled for
> the current process.
>
> With this patch, larger anonymous mappings are now THP aligned
> when checking in /proc/PID/maps, but only when THP is enabled
> for that process.
>
> Signed-off-by: Rik van Riel <riel@surriel.com>
> ---
>  mm/mmap.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index c035020d0c89..3a9d19cec690 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2229,6 +2229,9 @@ get_unmapped_area(struct file *file, unsigned long addr, unsigned long len,
>                  */
>                 pgoff = 0;
>                 get_area = shmem_get_unmapped_area;
> +       } else if (test_bit(MMF_VM_HUGEPAGE, &current->mm->flags)) {

There is a kind of chicken & egg problem here, MMF_VM_HUGEPAGE is not
going to be set if there is no THP eligible vma even though THP is
enabled.

> +               /* Ensures that larger anonymous mappings are THP aligned. */
> +               get_area = thp_get_unmapped_area;
>         }
>
>         addr = get_area(file, addr, len, pgoff, flags);
> --
> 2.37.1
>
>
Rik van Riel Aug. 9, 2022, 5:36 p.m. UTC | #4
On Tue, 2022-08-09 at 10:16 -0700, Yang Shi wrote:
> On Mon, Aug 8, 2022 at 1:47 PM Rik van Riel <riel@surriel.com> wrote:
> > 
> > Align larger anonymous memory mappings on THP boundaries by
> > going through thp_get_unmapped_area if THPs are enabled for
> > the current process.
> > 
> > With this patch, larger anonymous mappings are now THP aligned
> > when checking in /proc/PID/maps, but only when THP is enabled
> > for that process.
> > 
> > Signed-off-by: Rik van Riel <riel@surriel.com>
> > ---
> >  mm/mmap.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index c035020d0c89..3a9d19cec690 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -2229,6 +2229,9 @@ get_unmapped_area(struct file *file, unsigned
> > long addr, unsigned long len,
> >                  */
> >                 pgoff = 0;
> >                 get_area = shmem_get_unmapped_area;
> > +       } else if (test_bit(MMF_VM_HUGEPAGE, &current->mm->flags))
> > {
> 
> There is a kind of chicken & egg problem here, MMF_VM_HUGEPAGE is not
> going to be set if there is no THP eligible vma even though THP is
> enabled.

With THP enabled=always, we should always end up with getting
MMF_VM_HUGEPAGE set after the first VMA, but you are right that:

1) The first VMA might not get the proper alignment, and
2) with THP enabled=madvise we might get a whole bunch of
   mis-aligned VMAs on which a subsequent madvise would
   not create the desired THPs.

You are right that that condition should just be removed,
and we should decide alignment based on VMA size alone.

Let me send a v2.
diff mbox series

Patch

diff --git a/mm/mmap.c b/mm/mmap.c
index c035020d0c89..3a9d19cec690 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2229,6 +2229,9 @@  get_unmapped_area(struct file *file, unsigned long addr, unsigned long len,
 		 */
 		pgoff = 0;
 		get_area = shmem_get_unmapped_area;
+	} else if (test_bit(MMF_VM_HUGEPAGE, &current->mm->flags)) {
+		/* Ensures that larger anonymous mappings are THP aligned. */
+		get_area = thp_get_unmapped_area;
 	}
 
 	addr = get_area(file, addr, len, pgoff, flags);