Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230415000818.1955007-1-surenb@google.com> <ZD2gsbN2K66oXT69@x1n>
 <ZD3Nk0u+nxOT4snZ@casper.infradead.org>
In-Reply-To: <ZD3Nk0u+nxOT4snZ@casper.infradead.org>
From:   Suren Baghdasaryan <surenb@google.com>
Date:   Mon, 17 Apr 2023 16:17:45 -0700
Message-ID: <CAJuCfpFPziNK65qpzd5dEYSnoE-94UHAsM-CX080VTTJC5ZZKA@mail.gmail.com>
Subject: Re: [PATCH v2 1/1] mm: do not increment pgfault stats when page fault
 handler retries
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Apr 17, 2023 at 3:52=E2=80=AFPM 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).  T=
hat
> > > -    *   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 count=
ed
> > > -    *   once they're completed.
> > > +    * Do not account for incomplete faults (VM_FAULT_RETRY). They wi=
ll 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?

>