linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Suren Baghdasaryan <surenb@google.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Peter Xu <peterx@redhat.com>,
	akpm@linux-foundation.org, hannes@cmpxchg.org,  mhocko@suse.com,
	josef@toxicpanda.com, jack@suse.cz, ldufour@linux.ibm.com,
	 laurent.dufour@fr.ibm.com, michel@lespinasse.org,
	liam.howlett@oracle.com,  jglisse@google.com, vbabka@suse.cz,
	minchan@google.com, dave@stgolabs.net,
	 punit.agrawal@bytedance.com, lstoakes@gmail.com,
	linux-mm@kvack.org,  linux-kernel@vger.kernel.org,
	kernel-team@android.com
Subject: Re: [PATCH v2 1/1] mm: do not increment pgfault stats when page fault handler retries
Date: Mon, 17 Apr 2023 16:17:45 -0700	[thread overview]
Message-ID: <CAJuCfpFPziNK65qpzd5dEYSnoE-94UHAsM-CX080VTTJC5ZZKA@mail.gmail.com> (raw)
In-Reply-To: <ZD3Nk0u+nxOT4snZ@casper.infradead.org>

On Mon, Apr 17, 2023 at 3:52 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Mon, Apr 17, 2023 at 03:40:33PM -0400, Peter Xu wrote:
> > >     /*
> > > -    * We don't do accounting for some specific faults:
> > > -    *
> > > -    * - Unsuccessful faults (e.g. when the address wasn't valid).  That
> > > -    *   includes arch_vma_access_permitted() failing before reaching here.
> > > -    *   So this is not a "this many hardware page faults" counter.  We
> > > -    *   should use the hw profiling for that.
> > > -    *
> > > -    * - Incomplete faults (VM_FAULT_RETRY).  They will only be counted
> > > -    *   once they're completed.
> > > +    * Do not account for incomplete faults (VM_FAULT_RETRY). They will be
> > > +    * counted upon completion.
> > >      */
> > > -   if (ret & (VM_FAULT_ERROR | VM_FAULT_RETRY))
> > > +   if (ret & VM_FAULT_RETRY)
> > > +           return;
> > > +
> > > +   /* Register both successful and failed faults in PGFAULT counters. */
> > > +   count_vm_event(PGFAULT);
> > > +   count_memcg_event_mm(mm, PGFAULT);
> >
> > Is there reason on why vm events accountings need to be explicitly
> > different from perf events right below on handling ERROR?
>
> I think so.  ERROR is quite different from RETRY.  If we are, for
> example, handling a SIGSEGV (perhaps a GC language?) that should be
> accounted.  If we can't handle a page fault right now, and need to
> retry within the kernel, that should not be accounted.

IIUC, the question was about the differences in vm vs perf accounting
for errors, not the difference between ERROR and RETRY cases. Matthew,
are you answering the right question or did I misunderstand your
answer?

>


  reply	other threads:[~2023-04-17 23:18 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-15  0:08 Suren Baghdasaryan
2023-04-17 17:26 ` Matthew Wilcox
2023-04-17 19:40 ` Peter Xu
2023-04-17 20:29   ` Suren Baghdasaryan
2023-04-17 21:14     ` Peter Xu
2023-04-17 21:21       ` Suren Baghdasaryan
2023-04-17 22:52   ` Matthew Wilcox
2023-04-17 23:17     ` Suren Baghdasaryan [this message]
2023-04-18 14:25       ` Matthew Wilcox
2023-04-18 14:54         ` Suren Baghdasaryan
2023-04-18 15:08           ` Matthew Wilcox
2023-04-18 16:06             ` Peter Xu
2023-04-18 17:17               ` Suren Baghdasaryan
2023-04-18 21:48                 ` Suren Baghdasaryan
2023-04-18 22:45                   ` Peter Xu
2023-04-18 22:58                     ` Suren Baghdasaryan
2023-04-18 23:38                       ` Peter Xu
2023-04-19 18:00                         ` Suren Baghdasaryan
2023-04-17 21:26 ` Peter Xu
2023-04-17 22:47   ` Suren Baghdasaryan
2023-04-18 15:19     ` Peter Xu
2023-04-18 15:32       ` Matthew Wilcox
2023-04-18 15:48         ` Peter Xu
2023-04-18 16:45           ` Suren Baghdasaryan
2023-04-18 18:46             ` Peter Xu

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=CAJuCfpFPziNK65qpzd5dEYSnoE-94UHAsM-CX080VTTJC5ZZKA@mail.gmail.com \
    --to=surenb@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave@stgolabs.net \
    --cc=hannes@cmpxchg.org \
    --cc=jack@suse.cz \
    --cc=jglisse@google.com \
    --cc=josef@toxicpanda.com \
    --cc=kernel-team@android.com \
    --cc=laurent.dufour@fr.ibm.com \
    --cc=ldufour@linux.ibm.com \
    --cc=liam.howlett@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lstoakes@gmail.com \
    --cc=mhocko@suse.com \
    --cc=michel@lespinasse.org \
    --cc=minchan@google.com \
    --cc=peterx@redhat.com \
    --cc=punit.agrawal@bytedance.com \
    --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