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
> >>
>
next prev parent 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