Message ID | 20240129075305.3512138-1-yajun.deng@linux.dev |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-42310-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2087:b0:106:209c:c626 with SMTP id gs7csp417600dyb; Sun, 28 Jan 2024 23:56:42 -0800 (PST) X-Google-Smtp-Source: AGHT+IEyXZYXueOaf1CiSkEf/XHBypHon68mqw9gJF1CYGl+LhsslxaTpDaxzyKqRxmSV51D/RDZ X-Received: by 2002:a05:6830:55:b0:6dc:5754:8797 with SMTP id d21-20020a056830005500b006dc57548797mr4200975otp.7.1706515002437; Sun, 28 Jan 2024 23:56:42 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706515002; cv=pass; d=google.com; s=arc-20160816; b=zH03SOKvlvimQCEGswo417ACIS0ZD+zx49fhy9WMWXQiTfI0s5Wo89m+51FXH2wEF5 KzTd3mcxwEPSsmjfkSKhWc4EUSlbxkWOyaq/IFL+0VJx5aUHFdf9HgpSWEz1xVGFU26W bCSL0eToro6l5AG22/qVXd0KsOgOtE5/6LFy70gg6or3F0rg1Xg+Vo25ZjBeamIKX0aw V911SbT8pddxgyC+f/BHEL5FkA5FFbdrMGyOA9euaHm+VIe/j79LbGsDJEFOkMZWmCV/ WpEdkxLP0f7VEEWc5LFsfkQYUR34L32xxv/BOesF7ojppdCqYW8pCBpRJHDpPZfGAKnf gKag== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=I5LyXm335j6PMvtoknG0DUGXbxAqHQBfeRBYbfkRtTU=; fh=9dbTP+8qiE15iWU0P8jOF7HnY3DYTAEp9+Z7q4CVW+M=; b=t0jW5gYkX3zSmpikbyu4y/wn3alUcncZYs0iM+I6papPhPcAIB6sKV+hQ7YRbNcBgq kqKcXcbKdia07Bam+o7uS6VjfQTKdYKwXz11IJOIXag9dUApQXiHJcxU0XnW86ivP0ZM S2aaMNWw6UAQhvvbd+Yhmxqrzn7gZ4TRE78452VHl9nicKQs7oSWZCEdWB8aSnj1+bWQ Ug8AjD5HacP7sANHTPSrMYcTCKbwf00awD7uLBkTI/TsHtUjUsq4cUMixC618+Vizevj qSIRC4s+kB9z1Dh70JHlbUnb0rITmMxP2W9YMjv8ncyU80NP1MxZhTWKfMIlM870ylYJ xDsg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=u2n9Trm7; arc=pass (i=1 spf=pass spfdomain=linux.dev dkim=pass dkdomain=linux.dev dmarc=pass fromdomain=linux.dev); spf=pass (google.com: domain of linux-kernel+bounces-42310-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-42310-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id g28-20020a63375c000000b005cf9e5947fbsi5108959pgn.270.2024.01.28.23.56.42 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Jan 2024 23:56:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-42310-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=u2n9Trm7; arc=pass (i=1 spf=pass spfdomain=linux.dev dkim=pass dkdomain=linux.dev dmarc=pass fromdomain=linux.dev); spf=pass (google.com: domain of linux-kernel+bounces-42310-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-42310-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 35AA12842C1 for <ouuuleilei@gmail.com>; Mon, 29 Jan 2024 07:56:42 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0502A5820C; Mon, 29 Jan 2024 07:53:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="u2n9Trm7" Received: from out-176.mta0.migadu.com (out-176.mta0.migadu.com [91.218.175.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1CE7E57887 for <linux-kernel@vger.kernel.org>; Mon, 29 Jan 2024 07:53:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.176 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706514808; cv=none; b=WeY4ze9MX0zkEfrbJrUkMScsZqj+bmHJsvT169pWMKQvA/q4qrfuz2ZVf+Jali8s9zV3mdGpNwocpZWI2A/eiAKfta3BatbHkx2ZBlBOYr7q4z1lB3lDi6d+/NTfiMfN/YWZiOsm+m3BTxnlwW2fs4NxVscXY8SFMbrJJgV/3pg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706514808; c=relaxed/simple; bh=C5/YmQiOYf1bM02I+5RvLMrUrx0MMswr/SIee6klngA=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=APT1QDrj5bOlSbDYhzR1TJ0I5+qTooTiDJyiGRROksN1RTe6HmONLVhTMM/f95Ps6ErzDGGJvrUeYkmF8ngJ9vQSfRy100wUnh43cZATOjkvLmqOpy5zxMw6ts2TjeLCZl02dVAA4l47Z7QmwCuQ04vWaLvkr6yuq/+E8IuQEIE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=u2n9Trm7; arc=none smtp.client-ip=91.218.175.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1706514802; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=I5LyXm335j6PMvtoknG0DUGXbxAqHQBfeRBYbfkRtTU=; b=u2n9Trm7n2i4J+PRhNgk8iG8hI5XnpXnhkuFrieEV9sNBZejxTSo82JR4PRVtmGiqlPpcW Qj0mFqBZQ8QtaLyOZWaebB42+wu8VdcG2P69tzf1AVuDTsIxAD3KBwYTa2ZYpjPKPaHReN P164ETp3VFij3UD+/bPw0MjgY5ZKAJI= From: Yajun Deng <yajun.deng@linux.dev> To: akpm@linux-foundation.org Cc: Liam.Howlett@Oracle.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Yajun Deng <yajun.deng@linux.dev> Subject: [PATCH] mm/mmap: remove the mm parameter in vma_complete() Date: Mon, 29 Jan 2024 15:53:05 +0800 Message-Id: <20240129075305.3512138-1-yajun.deng@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789410675266630597 X-GMAIL-MSGID: 1789410675266630597 |
Series |
mm/mmap: remove the mm parameter in vma_complete()
|
|
Commit Message
Yajun Deng
Jan. 29, 2024, 7:53 a.m. UTC
There are vma_merge() and do_brk_flags() pass mm to vma_complete(), others
would pass the vma->vm_mm. The following explains that the mm is the
vma->vm_mm in vma_merge() and do_brk_flags().
All vma will point to the same mm struct if the vma_merge() is successful.
So the mm and the vma->mm are the same.
vm_brk_flags() and brk syscall will initialize vmi with current->mm,
so the vma->vm_mm and the current->mm are the same if vma exists in
do_brk_flags().
Remove the mm parameter in vma_complete() and get mm from the vma in vp.
Signed-off-by: Yajun Deng <yajun.deng@linux.dev>
---
mm/mmap.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
Comments
* Yajun Deng <yajun.deng@linux.dev> [240129 02:53]: > There are vma_merge() and do_brk_flags() pass mm to vma_complete(), others > would pass the vma->vm_mm. The following explains that the mm is the > vma->vm_mm in vma_merge() and do_brk_flags(). > > All vma will point to the same mm struct if the vma_merge() is successful. > So the mm and the vma->mm are the same. Absolutely, they must be the same. I don't think vma_merge() checks this, but it is true. > > vm_brk_flags() and brk syscall will initialize vmi with current->mm, > so the vma->vm_mm and the current->mm are the same if vma exists in > do_brk_flags(). > > Remove the mm parameter in vma_complete() and get mm from the vma in vp. You have added a dereference to the two paths that don't need it to reduce the argument list from 3 to 2. It's the same number of lines as well. vma_shrink() is only used on process creation, but brk is more common. Note that this function is marked as inline. I'm not sure this change is worth making. > > Signed-off-by: Yajun Deng <yajun.deng@linux.dev> > --- > mm/mmap.c | 16 ++++++++-------- > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/mm/mmap.c b/mm/mmap.c > index e97b9144c61a..9b968d1edf55 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -509,11 +509,11 @@ static inline void vma_prepare(struct vma_prepare *vp) > * > * @vp: The vma_prepare struct > * @vmi: The vma iterator > - * @mm: The mm_struct > */ > -static inline void vma_complete(struct vma_prepare *vp, > - struct vma_iterator *vmi, struct mm_struct *mm) > +static inline void vma_complete(struct vma_prepare *vp, struct vma_iterator *vmi) > { > + struct mm_struct *mm = vp->vma->vm_mm; > + > if (vp->file) { > if (vp->adj_next) > vma_interval_tree_insert(vp->adj_next, > @@ -666,7 +666,7 @@ int vma_expand(struct vma_iterator *vmi, struct vm_area_struct *vma, > vma_set_range(vma, start, end, pgoff); > vma_iter_store(vmi, vma); > > - vma_complete(&vp, vmi, vma->vm_mm); > + vma_complete(&vp, vmi); > return 0; > > nomem: > @@ -707,7 +707,7 @@ int vma_shrink(struct vma_iterator *vmi, struct vm_area_struct *vma, > > vma_iter_clear(vmi); > vma_set_range(vma, start, end, pgoff); > - vma_complete(&vp, vmi, vma->vm_mm); > + vma_complete(&vp, vmi); > return 0; > } > > @@ -1030,7 +1030,7 @@ static struct vm_area_struct > } > } > > - vma_complete(&vp, vmi, mm); > + vma_complete(&vp, vmi); > khugepaged_enter_vma(res, vm_flags); > return res; > > @@ -2377,7 +2377,7 @@ static int __split_vma(struct vma_iterator *vmi, struct vm_area_struct *vma, > } > > /* vma_complete stores the new vma */ > - vma_complete(&vp, vmi, vma->vm_mm); > + vma_complete(&vp, vmi); > > /* Success. */ > if (new_below) > @@ -3145,7 +3145,7 @@ static int do_brk_flags(struct vma_iterator *vmi, struct vm_area_struct *vma, > vm_flags_set(vma, VM_SOFTDIRTY); > vma_iter_store(vmi, vma); > > - vma_complete(&vp, vmi, mm); > + vma_complete(&vp, vmi); > khugepaged_enter_vma(vma, flags); > goto out; > } > -- > 2.25.1 > >
Adding Vlastimil and Lorenzo to discuss this patch. On 2024/1/29 23:04, Liam R. Howlett wrote: > * Yajun Deng <yajun.deng@linux.dev> [240129 02:53]: >> There are vma_merge() and do_brk_flags() pass mm to vma_complete(), others >> would pass the vma->vm_mm. The following explains that the mm is the >> vma->vm_mm in vma_merge() and do_brk_flags(). >> >> All vma will point to the same mm struct if the vma_merge() is successful. >> So the mm and the vma->mm are the same. > Absolutely, they must be the same. I don't think vma_merge() checks > this, but it is true. > >> vm_brk_flags() and brk syscall will initialize vmi with current->mm, >> so the vma->vm_mm and the current->mm are the same if vma exists in >> do_brk_flags(). >> >> Remove the mm parameter in vma_complete() and get mm from the vma in vp. > You have added a dereference to the two paths that don't need it to > reduce the argument list from 3 to 2. It's the same number of lines as > well. vma_shrink() is only used on process creation, but brk is more > common. Note that this function is marked as inline. > > I'm not sure this change is worth making. If we can make sure the mm is vma->vm_mm, I don't think we need to pass the mm. If we can't make sure that, this change is not worth it. >> Signed-off-by: Yajun Deng <yajun.deng@linux.dev> >> --- >> mm/mmap.c | 16 ++++++++-------- >> 1 file changed, 8 insertions(+), 8 deletions(-) >> >> diff --git a/mm/mmap.c b/mm/mmap.c >> index e97b9144c61a..9b968d1edf55 100644 >> --- a/mm/mmap.c >> +++ b/mm/mmap.c >> @@ -509,11 +509,11 @@ static inline void vma_prepare(struct vma_prepare *vp) >> * >> * @vp: The vma_prepare struct >> * @vmi: The vma iterator >> - * @mm: The mm_struct >> */ >> -static inline void vma_complete(struct vma_prepare *vp, >> - struct vma_iterator *vmi, struct mm_struct *mm) >> +static inline void vma_complete(struct vma_prepare *vp, struct vma_iterator *vmi) >> { >> + struct mm_struct *mm = vp->vma->vm_mm; >> + >> if (vp->file) { >> if (vp->adj_next) >> vma_interval_tree_insert(vp->adj_next, >> @@ -666,7 +666,7 @@ int vma_expand(struct vma_iterator *vmi, struct vm_area_struct *vma, >> vma_set_range(vma, start, end, pgoff); >> vma_iter_store(vmi, vma); >> >> - vma_complete(&vp, vmi, vma->vm_mm); >> + vma_complete(&vp, vmi); >> return 0; >> >> nomem: >> @@ -707,7 +707,7 @@ int vma_shrink(struct vma_iterator *vmi, struct vm_area_struct *vma, >> >> vma_iter_clear(vmi); >> vma_set_range(vma, start, end, pgoff); >> - vma_complete(&vp, vmi, vma->vm_mm); >> + vma_complete(&vp, vmi); >> return 0; >> } >> >> @@ -1030,7 +1030,7 @@ static struct vm_area_struct >> } >> } >> >> - vma_complete(&vp, vmi, mm); >> + vma_complete(&vp, vmi); >> khugepaged_enter_vma(res, vm_flags); >> return res; >> >> @@ -2377,7 +2377,7 @@ static int __split_vma(struct vma_iterator *vmi, struct vm_area_struct *vma, >> } >> >> /* vma_complete stores the new vma */ >> - vma_complete(&vp, vmi, vma->vm_mm); >> + vma_complete(&vp, vmi); >> >> /* Success. */ >> if (new_below) >> @@ -3145,7 +3145,7 @@ static int do_brk_flags(struct vma_iterator *vmi, struct vm_area_struct *vma, >> vm_flags_set(vma, VM_SOFTDIRTY); >> vma_iter_store(vmi, vma); >> >> - vma_complete(&vp, vmi, mm); >> + vma_complete(&vp, vmi); >> khugepaged_enter_vma(vma, flags); >> goto out; >> } >> -- >> 2.25.1 >> >>
* Yajun Deng <yajun.deng@linux.dev> [240222 05:26]: > Adding Vlastimil and Lorenzo to discuss this patch. > > > On 2024/1/29 23:04, Liam R. Howlett wrote: > > * Yajun Deng <yajun.deng@linux.dev> [240129 02:53]: > > > There are vma_merge() and do_brk_flags() pass mm to vma_complete(), others > > > would pass the vma->vm_mm. The following explains that the mm is the > > > vma->vm_mm in vma_merge() and do_brk_flags(). > > > > > > All vma will point to the same mm struct if the vma_merge() is successful. > > > So the mm and the vma->mm are the same. > > Absolutely, they must be the same. I don't think vma_merge() checks > > this, but it is true. > > > > > vm_brk_flags() and brk syscall will initialize vmi with current->mm, > > > so the vma->vm_mm and the current->mm are the same if vma exists in > > > do_brk_flags(). > > > > > > Remove the mm parameter in vma_complete() and get mm from the vma in vp. > > You have added a dereference to the two paths that don't need it to > > reduce the argument list from 3 to 2. It's the same number of lines as > > well. vma_shrink() is only used on process creation, but brk is more > > common. Note that this function is marked as inline. > > > > I'm not sure this change is worth making. > > If we can make sure the mm is vma->vm_mm, I don't think we need to pass the > mm. > > If we can't make sure that, this change is not worth it. We can be quite confident the mm struct is the same. The point is that you are causing more instructions for zero gain. There isn't a lot of arguments and this is marked inline. For most of the cases, we are already causing 1/2 the dereferences you are moving - except brk_flags(), which already has the pointer available. But instead of using the pointer already in a register, you are adding two new dereferences inside an inline function. This is like writing: struct mm_struct *mm = current->mm; struct vm_area_stuuct *vma = find_vma(mm, 0); .. use_the_mm(vma->vm_mm); . only it's worse than that because the compiler will replace use_the_mm() with the actual code in use_the_mm(), so we have effectively told the compiler to set another register up by dereferencing twice instead of using the value already available. It's a change for the sake of changing. You are not reducing the code size, you are not increasing the readability. You are adding two dereferences to brk() and one to all other callers. Why do this change? > > > > Signed-off-by: Yajun Deng <yajun.deng@linux.dev> > > > --- > > > mm/mmap.c | 16 ++++++++-------- > > > 1 file changed, 8 insertions(+), 8 deletions(-) > > > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > > index e97b9144c61a..9b968d1edf55 100644 > > > --- a/mm/mmap.c > > > +++ b/mm/mmap.c > > > @@ -509,11 +509,11 @@ static inline void vma_prepare(struct vma_prepare *vp) > > > * > > > * @vp: The vma_prepare struct > > > * @vmi: The vma iterator > > > - * @mm: The mm_struct > > > */ > > > -static inline void vma_complete(struct vma_prepare *vp, > > > - struct vma_iterator *vmi, struct mm_struct *mm) > > > +static inline void vma_complete(struct vma_prepare *vp, struct vma_iterator *vmi) > > > { > > > + struct mm_struct *mm = vp->vma->vm_mm; > > > + > > > if (vp->file) { > > > if (vp->adj_next) > > > vma_interval_tree_insert(vp->adj_next, > > > @@ -666,7 +666,7 @@ int vma_expand(struct vma_iterator *vmi, struct vm_area_struct *vma, > > > vma_set_range(vma, start, end, pgoff); > > > vma_iter_store(vmi, vma); > > > - vma_complete(&vp, vmi, vma->vm_mm); > > > + vma_complete(&vp, vmi); > > > return 0; > > > nomem: > > > @@ -707,7 +707,7 @@ int vma_shrink(struct vma_iterator *vmi, struct vm_area_struct *vma, > > > vma_iter_clear(vmi); > > > vma_set_range(vma, start, end, pgoff); > > > - vma_complete(&vp, vmi, vma->vm_mm); > > > + vma_complete(&vp, vmi); > > > return 0; > > > } > > > @@ -1030,7 +1030,7 @@ static struct vm_area_struct > > > } > > > } > > > - vma_complete(&vp, vmi, mm); > > > + vma_complete(&vp, vmi); > > > khugepaged_enter_vma(res, vm_flags); > > > return res; > > > @@ -2377,7 +2377,7 @@ static int __split_vma(struct vma_iterator *vmi, struct vm_area_struct *vma, > > > } > > > /* vma_complete stores the new vma */ > > > - vma_complete(&vp, vmi, vma->vm_mm); > > > + vma_complete(&vp, vmi); > > > /* Success. */ > > > if (new_below) > > > @@ -3145,7 +3145,7 @@ static int do_brk_flags(struct vma_iterator *vmi, struct vm_area_struct *vma, > > > vm_flags_set(vma, VM_SOFTDIRTY); > > > vma_iter_store(vmi, vma); > > > - vma_complete(&vp, vmi, mm); > > > + vma_complete(&vp, vmi); > > > khugepaged_enter_vma(vma, flags); > > > goto out; > > > } > > > -- > > > 2.25.1 > > > > > >
On 2024/2/23 00:22, Liam R. Howlett wrote: > * Yajun Deng <yajun.deng@linux.dev> [240222 05:26]: >> Adding Vlastimil and Lorenzo to discuss this patch. >> >> >> On 2024/1/29 23:04, Liam R. Howlett wrote: >>> * Yajun Deng <yajun.deng@linux.dev> [240129 02:53]: >>>> There are vma_merge() and do_brk_flags() pass mm to vma_complete(), others >>>> would pass the vma->vm_mm. The following explains that the mm is the >>>> vma->vm_mm in vma_merge() and do_brk_flags(). >>>> >>>> All vma will point to the same mm struct if the vma_merge() is successful. >>>> So the mm and the vma->mm are the same. >>> Absolutely, they must be the same. I don't think vma_merge() checks >>> this, but it is true. >>> >>>> vm_brk_flags() and brk syscall will initialize vmi with current->mm, >>>> so the vma->vm_mm and the current->mm are the same if vma exists in >>>> do_brk_flags(). >>>> >>>> Remove the mm parameter in vma_complete() and get mm from the vma in vp. >>> You have added a dereference to the two paths that don't need it to >>> reduce the argument list from 3 to 2. It's the same number of lines as >>> well. vma_shrink() is only used on process creation, but brk is more >>> common. Note that this function is marked as inline. >>> >>> I'm not sure this change is worth making. >> If we can make sure the mm is vma->vm_mm, I don't think we need to pass the >> mm. >> >> If we can't make sure that, this change is not worth it. > We can be quite confident the mm struct is the same. The point is that > you are causing more instructions for zero gain. There isn't a lot of > arguments and this is marked inline. For most of the cases, we are > already causing 1/2 the dereferences you are moving - except > brk_flags(), which already has the pointer available. But instead of > using the pointer already in a register, you are adding two new > dereferences inside an inline function. > > This is like writing: > > struct mm_struct *mm = current->mm; > struct vm_area_stuuct *vma = find_vma(mm, 0); > > ... > > use_the_mm(vma->vm_mm); > > .. only it's worse than that because the compiler will replace > use_the_mm() with the actual code in use_the_mm(), so we have > effectively told the compiler to set another register up by > dereferencing twice instead of using the value already available. > > It's a change for the sake of changing. > > You are not reducing the code size, you are not increasing the > readability. You are adding two dereferences to brk() and one to all > other callers. Why do this change? Thank you for your explanation. >>>> Signed-off-by: Yajun Deng <yajun.deng@linux.dev> >>>> --- >>>> mm/mmap.c | 16 ++++++++-------- >>>> 1 file changed, 8 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/mm/mmap.c b/mm/mmap.c >>>> index e97b9144c61a..9b968d1edf55 100644 >>>> --- a/mm/mmap.c >>>> +++ b/mm/mmap.c >>>> @@ -509,11 +509,11 @@ static inline void vma_prepare(struct vma_prepare *vp) >>>> * >>>> * @vp: The vma_prepare struct >>>> * @vmi: The vma iterator >>>> - * @mm: The mm_struct >>>> */ >>>> -static inline void vma_complete(struct vma_prepare *vp, >>>> - struct vma_iterator *vmi, struct mm_struct *mm) >>>> +static inline void vma_complete(struct vma_prepare *vp, struct vma_iterator *vmi) >>>> { >>>> + struct mm_struct *mm = vp->vma->vm_mm; >>>> + >>>> if (vp->file) { >>>> if (vp->adj_next) >>>> vma_interval_tree_insert(vp->adj_next, >>>> @@ -666,7 +666,7 @@ int vma_expand(struct vma_iterator *vmi, struct vm_area_struct *vma, >>>> vma_set_range(vma, start, end, pgoff); >>>> vma_iter_store(vmi, vma); >>>> - vma_complete(&vp, vmi, vma->vm_mm); >>>> + vma_complete(&vp, vmi); >>>> return 0; >>>> nomem: >>>> @@ -707,7 +707,7 @@ int vma_shrink(struct vma_iterator *vmi, struct vm_area_struct *vma, >>>> vma_iter_clear(vmi); >>>> vma_set_range(vma, start, end, pgoff); >>>> - vma_complete(&vp, vmi, vma->vm_mm); >>>> + vma_complete(&vp, vmi); >>>> return 0; >>>> } >>>> @@ -1030,7 +1030,7 @@ static struct vm_area_struct >>>> } >>>> } >>>> - vma_complete(&vp, vmi, mm); >>>> + vma_complete(&vp, vmi); >>>> khugepaged_enter_vma(res, vm_flags); >>>> return res; >>>> @@ -2377,7 +2377,7 @@ static int __split_vma(struct vma_iterator *vmi, struct vm_area_struct *vma, >>>> } >>>> /* vma_complete stores the new vma */ >>>> - vma_complete(&vp, vmi, vma->vm_mm); >>>> + vma_complete(&vp, vmi); >>>> /* Success. */ >>>> if (new_below) >>>> @@ -3145,7 +3145,7 @@ static int do_brk_flags(struct vma_iterator *vmi, struct vm_area_struct *vma, >>>> vm_flags_set(vma, VM_SOFTDIRTY); >>>> vma_iter_store(vmi, vma); >>>> - vma_complete(&vp, vmi, mm); >>>> + vma_complete(&vp, vmi); >>>> khugepaged_enter_vma(vma, flags); >>>> goto out; >>>> } >>>> -- >>>> 2.25.1 >>>> >>>>
diff --git a/mm/mmap.c b/mm/mmap.c index e97b9144c61a..9b968d1edf55 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -509,11 +509,11 @@ static inline void vma_prepare(struct vma_prepare *vp) * * @vp: The vma_prepare struct * @vmi: The vma iterator - * @mm: The mm_struct */ -static inline void vma_complete(struct vma_prepare *vp, - struct vma_iterator *vmi, struct mm_struct *mm) +static inline void vma_complete(struct vma_prepare *vp, struct vma_iterator *vmi) { + struct mm_struct *mm = vp->vma->vm_mm; + if (vp->file) { if (vp->adj_next) vma_interval_tree_insert(vp->adj_next, @@ -666,7 +666,7 @@ int vma_expand(struct vma_iterator *vmi, struct vm_area_struct *vma, vma_set_range(vma, start, end, pgoff); vma_iter_store(vmi, vma); - vma_complete(&vp, vmi, vma->vm_mm); + vma_complete(&vp, vmi); return 0; nomem: @@ -707,7 +707,7 @@ int vma_shrink(struct vma_iterator *vmi, struct vm_area_struct *vma, vma_iter_clear(vmi); vma_set_range(vma, start, end, pgoff); - vma_complete(&vp, vmi, vma->vm_mm); + vma_complete(&vp, vmi); return 0; } @@ -1030,7 +1030,7 @@ static struct vm_area_struct } } - vma_complete(&vp, vmi, mm); + vma_complete(&vp, vmi); khugepaged_enter_vma(res, vm_flags); return res; @@ -2377,7 +2377,7 @@ static int __split_vma(struct vma_iterator *vmi, struct vm_area_struct *vma, } /* vma_complete stores the new vma */ - vma_complete(&vp, vmi, vma->vm_mm); + vma_complete(&vp, vmi); /* Success. */ if (new_below) @@ -3145,7 +3145,7 @@ static int do_brk_flags(struct vma_iterator *vmi, struct vm_area_struct *vma, vm_flags_set(vma, VM_SOFTDIRTY); vma_iter_store(vmi, vma); - vma_complete(&vp, vmi, mm); + vma_complete(&vp, vmi); khugepaged_enter_vma(vma, flags); goto out; }