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;
Date:   Tue, 18 Apr 2023 12:06:11 -0400
From:   Peter Xu <peterx@redhat.com>
To:     Matthew Wilcox <willy@infradead.org>
Cc:     Suren Baghdasaryan <surenb@google.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
Message-ID: <ZD6/805XpvfZde0Y@x1n>
References: <20230415000818.1955007-1-surenb@google.com>
 <ZD2gsbN2K66oXT69@x1n>
 <ZD3Nk0u+nxOT4snZ@casper.infradead.org>
 <CAJuCfpFPziNK65qpzd5dEYSnoE-94UHAsM-CX080VTTJC5ZZKA@mail.gmail.com>
 <ZD6oVgIi/yY1+t1L@casper.infradead.org>
 <CAJuCfpFJ0owZELS2COukb0rHCOpqNMW-x9vVonkhknReZb=Zsg@mail.gmail.com>
 <ZD6yirD6Ob+1xG32@casper.infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ZD6yirD6Ob+1xG32@casper.infradead.org>
Precedence: bulk

On Tue, Apr 18, 2023 at 04:08:58PM +0100, Matthew Wilcox wrote:
> On Tue, Apr 18, 2023 at 07:54:01AM -0700, Suren Baghdasaryan wrote:
> > On Tue, Apr 18, 2023 at 7:25 AM Matthew Wilcox <willy@infradead.org> wrote:
> > >
> > > On Mon, Apr 17, 2023 at 04:17:45PM -0700, Suren Baghdasaryan wrote:
> > > > 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?
> > >
> > > Maybe I'm misunderstanding what you're proposing.  I thought the
> > > proposal was to make neither ERROR nor RETRY increment the counters,
> > > but if the proposal is to make ERROR increment the perf counters
> > > instead, then that's cool with me.
> > 
> > Oh, I think now I understand your answer. You were not highlighting
> > the difference between the who but objecting to the proposal of not
> > counting both ERROR and RETRY. Am I on the same page now?
> 
> I think so.  Let's see your patch and then we can be sure we're talking
> about the same thing ;-)

IMHO if there's no explicit reason to differenciate the events, we should
always account them the same way for vm,perf,... either with ERROR
accounted or not.

I am not sure whether accounting ERROR faults would matter for a mprotect()
use case, because they shouldn't rely on the counter to work but the SIGBUS
itself to be generated on page accesses with the sighandler doing work.

One trivial benefit of keep accounting ERROR is we only need to modify vm
account ABI so both RETRY & ERROR will be adjusted to match perf,task
counters.  OTOH we can also change all to take ERROR into account, but then
we're modifying ABI for all counters.

-- 
Peter Xu