linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Liam Howlett <liam.howlett@oracle.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: "Jakub Matěna" <matenajakub@gmail.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"patches@lists.linux.dev" <patches@lists.linux.dev>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mhocko@kernel.org" <mhocko@kernel.org>,
	"mgorman@techsingularity.net" <mgorman@techsingularity.net>,
	"willy@infradead.org" <willy@infradead.org>,
	"hughd@google.com" <hughd@google.com>,
	"kirill@shutemov.name" <kirill@shutemov.name>,
	"riel@surriel.com" <riel@surriel.com>,
	"rostedt@goodmis.org" <rostedt@goodmis.org>,
	"peterz@infradead.org" <peterz@infradead.org>
Subject: Re: [RFC PATCH 4/4] [PATCH 4/4] mm: add tracing for VMA merges
Date: Fri, 25 Feb 2022 14:07:14 +0000	[thread overview]
Message-ID: <20220225140708.onog34i7xp2d7geh@revolver> (raw)
In-Reply-To: <d7f56188-5512-1365-243a-1e70acddf5c1@suse.cz>

* Vlastimil Babka <vbabka@suse.cz> [220225 05:39]:
> On 2/18/22 20:57, Liam Howlett wrote:
> >>  	/*
> >>  	 * Can we merge both predecessor and successor?
> >>  	 */
> >> -	if (merge_prev && merge_next)
> >> +	if (merge_prev >= MERGE_OK && merge_next >= MERGE_OK) {
> > 
> > What happened to making vma_merge easier to read?  What does > MERGE_OK
> > mean?  I guess this answers why booleans were not used, but I don't like
> 
> It's similar to e.g. enum compact_priority where specific values are defined
> as well as more abstract aliases.
> 
> > it.   Couldn't you just log the err/success and the value of
> > merge_prev/merge_next?  It's not like the code tries more than one way
> > of merging on failure..
> 
> An initial version had the "log" (trace point really) at multiple places and
> it was uglier than collecting details in the variables and having a single
> tracepoint call site.

Wouldn't the success/failure, merge_prev, and merge_next be all we need
to know what happened?  This could be places near the end of the
function.  It doesn't say why merge_prev or merge_next was set to false
but I think that's enough for most uses?

> 
> Note that the tracepoint is being provided as part of the series mainly to
> allow evaluation of the series. If it's deemed too specific to be included
> in mainline in the end, so be it.

Ah, in that case use bool until we arrive at this patch, then change
merge_* to int.

> 
> >>  		merge_both = is_mergeable_anon_vma(prev->anon_vma, next->anon_vma, NULL);
> >> +	}
> >>  
> >> -	if (merge_both) {	 /* cases 1, 6 */
> >> +	if (merge_both >= MERGE_OK) {	 /* cases 1, 6 */
> >>  		err = __vma_adjust(prev, prev->vm_start,
> >>  					next->vm_end, prev->vm_pgoff, NULL,
> >>  					prev);
> >>  		area = prev;
> >> -	} else if (merge_prev) {			/* cases 2, 5, 7 */
> >> +	} else if (merge_prev >= MERGE_OK) {			/* cases 2, 5, 7 */
> >>  		err = __vma_adjust(prev, prev->vm_start,
> >>  					end, prev->vm_pgoff, NULL, prev);
> >>  		area = prev;
> >> -	} else if (merge_next) {
> >> +	} else if (merge_next >= MERGE_OK) {
> >>  		if (prev && addr < prev->vm_end)	/* case 4 */
> >>  			err = __vma_adjust(prev, prev->vm_start,
> >>  					addr, prev->vm_pgoff, NULL, next);
> >> @@ -1252,7 +1255,7 @@ struct vm_area_struct *vma_merge(struct mm_struct *mm,
> >>  	} else {
> >>  		err = -1;
> >>  	}
> >> -
> >> +	trace_vm_av_merge(err, merge_prev, merge_next, merge_both);
> >>  	/*
> >>  	 * Cannot merge with predecessor or successor or error in __vma_adjust?
> >>  	 */
> >> @@ -3359,6 +3362,8 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap,
> >>  		/*
> >>  		 * Source vma may have been merged into new_vma
> >>  		 */
> >> +		trace_vm_pgoff_merge(vma, anon_pgoff_updated);
> >> +
> >>  		if (unlikely(vma_start >= new_vma->vm_start &&
> >>  			     vma_start < new_vma->vm_end)) {
> >>  			/*
> >> -- 
> >> 2.34.1
> >> 
> 

  reply	other threads:[~2022-02-25 14:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-18 12:20 [RFC PATCH 0/4] Removing limitations of merging anonymous VMAs Jakub Matěna
2022-02-18 12:20 ` [RFC PATCH 1/4] [PATCH 1/4] mm: refactor of vma_merge() Jakub Matěna
2022-02-18 19:43   ` Liam Howlett
2022-02-25 14:26     ` Jakub Matěna
2022-02-18 12:20 ` [RFC PATCH 2/4] [PATCH 2/4] mm: adjust page offset in mremap Jakub Matěna
2022-02-18 19:50   ` Liam Howlett
2022-03-01 14:31     ` Jakub Matěna
2022-02-18 12:20 ` [RFC PATCH 3/4] [PATCH 3/4] mm: enable merging of VMAs with different anon_vmas Jakub Matěna
2022-02-18 12:20 ` [RFC PATCH 4/4] [PATCH 4/4] mm: add tracing for VMA merges Jakub Matěna
2022-02-18 18:09   ` Steven Rostedt
2022-02-18 18:46     ` Matthew Wilcox
2022-02-18 19:23       ` Steven Rostedt
2022-02-18 19:57   ` Liam Howlett
2022-02-25 10:39     ` Vlastimil Babka
2022-02-25 14:07       ` Liam Howlett [this message]
2022-02-18 19:21 ` [RFC PATCH 0/4] Removing limitations of merging anonymous VMAs Liam Howlett
2022-02-25 10:31   ` Vlastimil Babka
2022-02-25 14:24     ` Liam Howlett

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=20220225140708.onog34i7xp2d7geh@revolver \
    --to=liam.howlett@oracle.com \
    --cc=hughd@google.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matenajakub@gmail.com \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=peterz@infradead.org \
    --cc=riel@surriel.com \
    --cc=rostedt@goodmis.org \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox