linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: "Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Jann Horn <jannh@google.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] mm: completely abstract unnecessary adj_start calculation
Date: Wed, 29 Jan 2025 16:42:06 +0100	[thread overview]
Message-ID: <ba868c91-10ea-4f83-941b-c92291af3723@suse.cz> (raw)
In-Reply-To: <ef00aec42a892fe6ac9557b3a11f18f30a2e51b3.1737929364.git.lorenzo.stoakes@oracle.com>

On 1/27/25 16:50, Lorenzo Stoakes wrote:
> The adj_start calculation has been a constant source of confusion in the
> VMA merge code.
> 
> There are two cases to consider, one where we adjust the start of the
> vmg->middle VMA (i.e. the __VMG_FLAG_ADJUST_MIDDLE_START merge flag is
> set), in which case adj_start is calculated as:
> 
> (1) adj_start = vmg->end - vmg->middle->vm_start
> 
> And the case where we adjust the start of the vmg->next VMA (i.e.t he
> __VMG_FLAG_ADJUST_NEXT_START merge flag is set), in which case adj_start is
> calculated as:
> 
> (2) adj_start = -(vmg->middle->vm_end - vmg->end)
> 
> We apply (1) thusly:
> 
> vmg->middle->vm_start =
> 	vmg->middle->vm_start + vmg->end - vmg->middle->vm_start
> 
> Which simplifies to:
> 
> vmg->middle->vm_start = vmg->end
> 
> Similarly, we apply (2) as:
> 
> vmg->next->vm_start =
> 	vmg->next->vm_start + -(vmg->middle->vm_end - vmg->end)
> 
> Noting that for these VMAs to be mergeable vmg->middle->vm_end ==
> vmg->next->vm_start and so this simplifies to:
> 
> vmg->next->vm_start =
> 	vmg->next->vm_start + -(vmg->next->vm_start - vmg->end)
> 
> Which simplifies to:
> 
> vmg->next->vm_start = vmg->end
> 
> Therefore in each case, we simply need to adjust the start of the VMA to
> vmg->end (!) and can do away with this adj_start calculation. The only
> caveat is that we must ensure we update the vm_pgoff field correctly.
> 
> We therefore abstract this entire calculation to a new function
> vmg_adjust_set_range() which performs this calculation and sets the
> adjusted VMA's new range using the general vma_set_range() function.
> 
> We also must update vma_adjust_trans_huge() which expects the
> now-abstracted adj_start parameter. It turns out this is wholly
> unnecessary.
> 
> In vma_adjust_trans_huge() the relevant code is:
> 
> 	if (adjust_next > 0) {
> 		struct vm_area_struct *next = find_vma(vma->vm_mm, vma->vm_end);
> 		unsigned long nstart = next->vm_start;
> 		nstart += adjust_next;
> 		split_huge_pmd_if_needed(next, nstart);
> 	}
> 
> The only case where this is relevant is when __VMG_FLAG_ADJUST_MIDDLE_START
> is specified (in which case adj_next would have been positive), i.e. the
> one in which the vma specified is vmg->prev and this the sought 'next' VMA
> would be vmg->middle.
> 
> We can therefore eliminate the find_vma() invocation altogether and simply
> provide the vmg->middle VMA in this instance, or NULL otherwise.
> 
> Again we have an adj_next offset calculation:
> 
> next->vm_start + vmg->end - vmg->middle->vm_start
> 
> Where next == vmg->middle this simplifies to vmg->end as previously
> demonstrated.
> 
> Therefore nstart is equal to vmg->end, which is already passed to
> vma_adjust_trans_huge() via the 'end' parameter and so this code (rather
> delightfully) simplifies to:
> 
> 	if (next)
> 		split_huge_pmd_if_needed(next, end);
> 
> With these changes in place, it becomes silly for commit_merge() to return
> vmg->target, as it is always the same and threaded through vmg, so we
> finally change commit_merge() to return an error value once again.
> 
> This patch has no change in functional behaviour.
> 
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

Yeah this makes the preparations worth it. Nice!

Reviewed-by: Vlastimil Babka <vbabka@suse.cz>

> +/*
> + * Actually perform the VMA merge operation.
> + *
> + * On success, returns the merged VMA. Otherwise returns NULL.

Needs updating?

> + */
> +static int commit_merge(struct vma_merge_struct *vmg)
> +{
> +	struct vm_area_struct *vma;
> +	struct vma_prepare vp;
> +	bool adj_middle = vmg->merge_flags & __VMG_FLAG_ADJUST_MIDDLE_START;
>  
> -		vma_iter_config(vmg->vmi, vmg->next->vm_start + adj_start,
> -				vmg->next->vm_end);
> +	if (vmg->merge_flags & __VMG_FLAG_ADJUST_NEXT_START) {
> +		/* In this case we manipulate middle and return next. */

Also we don't return next anymore? At least not here.
vma_merge_existing_range() does, but here it's rather "the target is next"?

> +		vma = vmg->middle;
> +		vma_iter_config(vmg->vmi, vmg->end, vmg->next->vm_end);
>  	} else {


  parent reply	other threads:[~2025-01-29 15:42 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-27 15:50 [PATCH 0/5] mm: further simplify VMA merge operation Lorenzo Stoakes
2025-01-27 15:50 ` [PATCH 1/5] mm: simplify vma merge structure and expand comments Lorenzo Stoakes
2025-01-28 11:38   ` Vlastimil Babka
2025-01-28 14:05     ` Lorenzo Stoakes
2025-01-27 15:50 ` [PATCH 2/5] mm: further refactor commit_merge() Lorenzo Stoakes
2025-01-28 15:05   ` Vlastimil Babka
2025-01-28 15:45   ` Vlastimil Babka
2025-01-28 16:07     ` Lorenzo Stoakes
2025-01-28 16:42       ` Lorenzo Stoakes
2025-01-27 15:50 ` [PATCH 3/5] mm: eliminate adj_start parameter from commit_merge() Lorenzo Stoakes
2025-01-29 14:13   ` Vlastimil Babka
2025-01-29 14:19     ` Lorenzo Stoakes
2025-01-27 15:50 ` [PATCH 4/5] mm: make vmg->target consistent and further simplify commit_merge() Lorenzo Stoakes
2025-01-29 14:45   ` Vlastimil Babka
2025-01-29 14:51     ` Lorenzo Stoakes
2025-01-29 15:19   ` Vlastimil Babka
2025-01-29 15:30     ` Lorenzo Stoakes
2025-01-27 15:50 ` [PATCH 5/5] mm: completely abstract unnecessary adj_start calculation Lorenzo Stoakes
2025-01-27 18:50   ` kernel test robot
2025-01-27 18:56     ` Lorenzo Stoakes
2025-01-27 19:58     ` Lorenzo Stoakes
2025-01-27 20:13   ` kernel test robot
2025-01-27 20:35   ` kernel test robot
2025-01-28  7:54   ` kernel test robot
2025-01-29 15:42   ` Vlastimil Babka [this message]
2025-01-29 16:19     ` Lorenzo Stoakes

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=ba868c91-10ea-4f83-941b-c92291af3723@suse.cz \
    --to=vbabka@suse.cz \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox