All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joshua Hahn <joshua.hahnjy@gmail.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Hugh Dickins <hughd@google.com>,
	 Baolin Wang <baolin.wang@linux.alibaba.com>,
	Gregory Price <gourry@gourry.net>, Zi Yan <ziy@nvidia.com>,
	 Rakie Kim <rakie.kim@sk.com>,
	Ying Huang <ying.huang@linux.alibaba.com>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	 "Liam R. Howlett" <liam@infradead.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	 Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	 Michal Hocko <mhocko@suse.com>, Jonathan Corbet <corbet@lwn.net>,
	 Shuah Khan <skhan@linuxfoundation.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	linux-mm@kvack.org,  linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH 1/2] mm/mempolicy: merge adjacent shared policy ranges
Date: Fri, 13 Nov 2026 14:23:08 -0800	[thread overview]
Message-ID: <aveNgfkmfZ2SMWK8@devbig011.atn3.facebook.com> (raw)
In-Reply-To: <20261113-mempolicy_limit-v1-1-16688b2644dc@kernel.org>

On Fri, Nov 13, 2026 at 10:36:12PM +0100, David Hildenbrand (Arm) wrote:
> Shared policies can retain separate tree nodes for adjacent ranges with
> identical policies. This can create unnecessary policy ranges especially
> when individual VMAs cover individual file ranges, and user space sets
> the policy on these VMAs independently.
> 
> Extend the existing replacement handling to merge ranges with equal policy
> at either boundary. The existing replacement loop will then remove the old
> nodes and installs a single node for the combined range. This also avoids
> splitting an existing node when setting the same policy on a subrange.
> 
> Extending either boundary rules out splitting an existing node, so the
> allocation retry can only occur with the originally requested range.

Hi David,

Independent of 2/2 I think this is a really great change. Thank you!
Reviewed-by: Joshua Hahn <joshua.hahnjy@gmail.com>

> This change will make it easier to cap the number of shared policy
> ranges per inode.
> 
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> ---
>  mm/mempolicy.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index 06b90903e8794..183bc3bd077cd 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -3208,6 +3208,23 @@ static int shared_policy_replace(struct shared_policy *sp, pgoff_t start,
>  
>  restart:
>  	write_lock(&sp->lock);
> +	if (new) {
> +		/* Try to merge ranges with same policies. */
> +		if (start) {
> +			n = sp_lookup(sp, start - 1, start);
> +			if (n && mpol_equal(n->policy, new->policy)) {
> +				new->start = n->start;
> +				start = new->start;
> +			}
> +		}
> +		if (end != ULONG_MAX) {
> +			n = sp_lookup(sp, end, end + 1);
> +			if (n && mpol_equal(n->policy, new->policy)) {
> +				new->end = n->end;
> +				end = new->end;
> +			}
> +		}
> +	}
>  	n = sp_lookup(sp, start, end);
>  	/* Take care of old policies in the same range. */
>  	while (n && n->start < end) {
> 
> -- 
> 2.43.0
> 

  reply	other threads:[~2026-11-13 22:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-13 21:36 [PATCH 0/2] mm/mempolicy: shared policy limits for tmpfs/shmem/guest_memfd David Hildenbrand (Arm)
2026-11-13 21:36 ` [PATCH 1/2] mm/mempolicy: merge adjacent shared policy ranges David Hildenbrand (Arm)
2026-11-13 22:23   ` Joshua Hahn [this message]
2026-11-13 21:36 ` [PATCH 2/2] mm/mempolicy: limit shared policy ranges per inode David Hildenbrand (Arm)

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=aveNgfkmfZ2SMWK8@devbig011.atn3.facebook.com \
    --to=joshua.hahnjy@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=corbet@lwn.net \
    --cc=david@kernel.org \
    --cc=gourry@gourry.net \
    --cc=hughd@google.com \
    --cc=liam@infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=rakie.kim@sk.com \
    --cc=rdunlap@infradead.org \
    --cc=rppt@kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=ying.huang@linux.alibaba.com \
    --cc=ziy@nvidia.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.