From: Peter Xu <peterx@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Guo Ren <guoren@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andrea Arcangeli <aarcange@redhat.com>,
linux-csky@vger.kernel.org
Subject: Re: [PATCH 07/25] mm/csky: Use mm_fault_accounting()
Date: Thu, 18 Jun 2020 17:24:30 -0400 [thread overview]
Message-ID: <20200618212430.GO76766@xz-x1> (raw)
In-Reply-To: <CAHk-=whFEZbTJZaNwEkyevUV2aqRwbeVmtp6hhk1sK2mW4vaGA@mail.gmail.com>
On Thu, Jun 18, 2020 at 10:15:50AM -0700, Linus Torvalds wrote:
> On Thu, Jun 18, 2020 at 7:38 AM Peter Xu <peterx@redhat.com> wrote:
> >
> > GUP needs the per-task accounting, but not the perf events. We can do that by
> > slightly changing the new approach into:
> >
> > bool major = (ret & VM_FAULT_MAJOR) || (flags & FAULT_FLAG_TRIED);
> >
> > if (major)
> > current->maj_flt++;
> > else
> > current->min_flt++;
> >
> > if (!regs)
> > return ret;
> >
> > if (major)
> > perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MAJ, 1, regs, address);
> > else
> > perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MIN, 1, regs, address);
>
> Ack, I think this is the right thing to do.
>
> No normal situation will ever notice the difference, with remote
> accesses being as rare and specialized as they are. But being able to
> remote the otherwise unused 'tsk' parameter sounds like the right
> thing to do too.
>
> It might be worth adding a comment about why.
>
> Also, honestly, how about we remove the 'major' variable entirely, and
> instead make the code be something like
>
> unsigned long *flt;
> int event_type;
> ...
>
> /* Major fault */
> if ((ret & VM_FAULT_MAJOR) || (flags & FAULT_FLAG_TRIED)) {
> flt = ¤t->maj_flt;
> event_type = PERF_COUNT_SW_PAGE_FAULTS_MAJ;
> } else {
> flt = ¤t->min_flt;
> event_type = PERF_COUNT_SW_PAGE_FAULTS_MIN;
> }
> *flt++;
> if (regs)
> perf_sw_event(event_type, 1, regs, address);
>
> instead. Less source code duplication, and I bet it improves code
> generation too.
Will do. Thanks!
--
Peter Xu
next prev parent reply other threads:[~2020-06-18 21:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200615221607.7764-1-peterx@redhat.com>
2020-06-15 22:15 ` [PATCH 07/25] mm/csky: Use mm_fault_accounting() Peter Xu
2020-06-17 7:04 ` Guo Ren
2020-06-17 15:49 ` Peter Xu
2020-06-17 17:53 ` Linus Torvalds
2020-06-17 19:58 ` Peter Xu
2020-06-17 20:15 ` Linus Torvalds
2020-06-18 14:38 ` Peter Xu
2020-06-18 17:15 ` Linus Torvalds
2020-06-18 21:24 ` Peter Xu [this message]
2020-06-18 22:28 ` Peter Xu
2020-06-18 22:59 ` Linus Torvalds
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=20200618212430.GO76766@xz-x1 \
--to=peterx@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=gerald.schaefer@de.ibm.com \
--cc=guoren@kernel.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).