All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Rick Edgecombe <rick.p.edgecombe@intel.com>
Cc: Liam.Howlett@oracle.com, akpm@linux-foundation.org,
	debug@rivosinc.com, broonie@kernel.org,
	kirill.shutemov@linux.intel.com, keescook@chromium.org,
	tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org, luto@kernel.org,
	peterz@infradead.org, hpa@zytor.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/8] mm: Switch mm->get_unmapped_area() to a flag
Date: Wed, 21 Feb 2024 09:10:02 +0200	[thread overview]
Message-ID: <ZdWhylSaUwZkdDFb@kernel.org> (raw)
In-Reply-To: <20240215231332.1556787-2-rick.p.edgecombe@intel.com>

On Thu, Feb 15, 2024 at 03:13:25PM -0800, Rick Edgecombe wrote:
> The mm_struct contains a function pointer *get_unmapped_area(), which
> is set to either arch_get_unmapped_area() or
> arch_get_unmapped_area_topdown() during the initialization of the mm.
> 
> Since the function pointer only ever points to two functions that are named
> the same across all arch's, a function pointer is not really required. In
> addition future changes will want to add versions of the functions that
> take additional arguments. So to save a pointers worth of bytes in
> mm_struct, and prevent adding additional function pointers to mm_struct in
> future changes, remove it and keep the information about which
> get_unmapped_area() to use in a flag.
> 
> Introduce a helper, mm_get_unmapped_area(), to easily convert code that
> refers to the old function pointer to instead select and call either
> arch_get_unmapped_area() or arch_get_unmapped_area_topdown() based on the
> flag. Then drop the mm->get_unmapped_area() function pointer. Leave the
> get_unmapped_area() pointer in struct file_operations alone. The main
> purpose of this change is to reorganize in preparation for future changes,
> but it also converts the calls of mm->get_unmapped_area() from indirect
> branches into a direct ones.
> 
> The stress-ng bigheap benchmark calls realloc a lot, which calls through
> get_unmapped_area() in the kernel. On x86, the change yielded a ~4%
> improvement there. (bogo ops/s (usr+sys time))
> 
> In testing a few x86 configs, removing the pointer unfortunately didn't
> result in any actual size reductions in the compiled layout of mm_struct.
> But depending on compiler or arch alignment requirements, the change could
> possibly shrink the size of mm_struct.
> 
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> ---
>  arch/s390/mm/hugetlbpage.c       |  2 +-
>  arch/s390/mm/mmap.c              |  4 ++--
>  arch/sparc/kernel/sys_sparc_64.c | 15 ++++++---------
>  arch/sparc/mm/hugetlbpage.c      |  2 +-
>  arch/x86/kernel/cpu/sgx/driver.c |  2 +-
>  arch/x86/mm/hugetlbpage.c        |  2 +-
>  arch/x86/mm/mmap.c               |  4 ++--
>  drivers/char/mem.c               |  2 +-
>  drivers/dax/device.c             |  6 +++---
>  fs/hugetlbfs/inode.c             |  2 +-
>  fs/proc/inode.c                  | 15 ++++++++-------
>  fs/ramfs/file-mmu.c              |  2 +-
>  include/linux/mm_types.h         |  6 +-----
>  include/linux/sched/coredump.h   |  1 +
>  include/linux/sched/mm.h         |  5 +++++
>  io_uring/io_uring.c              |  2 +-
>  mm/debug.c                       |  6 ------
>  mm/huge_memory.c                 |  6 +++---
>  mm/mmap.c                        | 21 ++++++++++++++++++---
>  mm/shmem.c                       | 11 +++++------
>  mm/util.c                        |  6 +++---
>  21 files changed, 65 insertions(+), 57 deletions(-)
> 
> diff --git a/include/linux/sched/coredump.h b/include/linux/sched/coredump.h
> index 02f5090ffea2..428e440424c5 100644
> --- a/include/linux/sched/coredump.h
> +++ b/include/linux/sched/coredump.h
> @@ -74,6 +74,7 @@ static inline int get_dumpable(struct mm_struct *mm)
>  #define MMF_DISABLE_THP_MASK	(1 << MMF_DISABLE_THP)
>  #define MMF_OOM_REAP_QUEUED	25	/* mm was queued for oom_reaper */
>  #define MMF_MULTIPROCESS	26	/* mm is shared between processes */
> +#define MMF_TOPDOWN		27	/* mm is shared between processes */

Nit: you may want to update the comment here ;-)

>  /*
>   * MMF_HAS_PINNED: Whether this mm has pinned any pages.  This can be either
>   * replaced in the future by mm.pinned_vm when it becomes stable, or grow into

-- 
Sincerely yours,
Mike.


  parent reply	other threads:[~2024-02-21  7:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15 23:13 [RFC PATCH 0/8] Cover a guard gap corner case Rick Edgecombe
2024-02-15 23:13 ` [RFC PATCH 1/8] mm: Switch mm->get_unmapped_area() to a flag Rick Edgecombe
2024-02-16  0:30   ` Dave Hansen
2024-02-16  2:15     ` Liam R. Howlett
2024-02-16 12:30   ` Kirill A. Shutemov
2024-02-16 21:42     ` Edgecombe, Rick P
2024-02-21  7:10   ` Mike Rapoport [this message]
2024-02-21 16:59     ` Edgecombe, Rick P
2024-02-15 23:13 ` [RFC PATCH 2/8] mm: Introduce arch_get_unmapped_area_vmflags() Rick Edgecombe
2024-02-15 23:13 ` [RFC PATCH 3/8] mm: Use get_unmapped_area_vmflags() Rick Edgecombe
2024-02-16 12:56   ` Kirill A. Shutemov
2024-02-16 22:15     ` Edgecombe, Rick P
2024-02-17 12:35       ` kirill.shutemov
2024-02-15 23:13 ` [RFC PATCH 4/8] thp: Add thp_get_unmapped_area_vmflags() Rick Edgecombe
2024-02-16 12:59   ` Kirill A. Shutemov
2024-02-16 22:21     ` Edgecombe, Rick P
2024-02-17 12:57       ` kirill.shutemov
2024-02-15 23:13 ` [RFC PATCH 5/8] mm: Take placement mappings gap into account Rick Edgecombe
2024-02-16 13:12   ` Kirill A. Shutemov
2024-02-17  1:11     ` Edgecombe, Rick P
2024-02-20 16:48       ` Edgecombe, Rick P
2024-02-15 23:13 ` [RFC PATCH 6/8] x86/mm: Implement HAVE_ARCH_UNMAPPED_AREA_VMFLAGS Rick Edgecombe
2024-02-15 23:13 ` [RFC PATCH 7/8] x86/mm: Care about shadow stack guard gap during placement Rick Edgecombe
2024-02-15 23:13 ` [RFC PATCH 8/8] selftests/x86: Add placement guard gap test for shstk Rick Edgecombe

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=ZdWhylSaUwZkdDFb@kernel.org \
    --to=rppt@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=broonie@kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=debug@rivosinc.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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.