lkml.org 
[lkml]   [2020]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 00/25] mm: Page fault accounting cleanups
    On Wed, Jun 17, 2020 at 09:04:06AM +0100, Will Deacon wrote:
    > On Wed, Jun 17, 2020 at 10:55:14AM +1000, Michael Ellerman wrote:
    > > Linus Torvalds <torvalds@linux-foundation.org> writes:
    > > > On Mon, Jun 15, 2020 at 3:16 PM Peter Xu <peterx@redhat.com> wrote:
    > > >> This series tries to address all of them by introducing mm_fault_accounting()
    > > >> first, so that we move all the page fault accounting into the common code base,
    > > >> then call it properly from arch pf handlers just like handle_mm_fault().
    > > >
    > > > Hmm.
    > > >
    > > > So having looked at this a bit more, I'd actually like to go even
    > > > further, and just get rid of the per-architecture code _entirely_.
    > >
    > > <snip>
    > >
    > > > One detail worth noting: I do wonder if we should put the
    > > >
    > > > perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, addr);
    > > >
    > > > just in the arch code at the top of the fault handling, and consider
    > > > it entirely unrelated to the major/minor fault handling. The
    > > > major/minor faults fundamnetally are about successes. But the plain
    > > > PERF_COUNT_SW_PAGE_FAULTS could be about things that fail, including
    > > > things that never even get to this point at all.
    > >
    > > Yeah I think we should keep it in the arch code at roughly the top.
    >
    > I agree. It's a nice idea to consolidate the code, but I don't see that
    > it's really possible for PERF_COUNT_SW_PAGE_FAULTS without significantly
    > changing the semantics (and a potentially less useful way. Of course,
    > moving more of do_page_fault() out of the arch code would be great, but
    > that's a much bigger effort.
    >
    > > If it's moved to the end you could have a process spinning taking bad
    > > page faults (and fixing them up), and see no sign of it from the perf
    > > page fault counters.
    >
    > The current arm64 behaviour is that we record PERF_COUNT_SW_PAGE_FAULTS
    > if _all_ of the following are true:
    >
    > 1. The fault isn't handled by kprobes
    > 2. The pagefault handler is enabled
    > 3. We have an mm (current->mm)
    > 4. The fault isn't an unexpected kernel fault on a user address (we oops
    > and kill the task in this case)
    >
    > Which loosely corresponds to "we took a fault on a user address that it
    > looks like we can handle".
    >
    > That said, I'm happy to tweak this if it brings us into line with other
    > architectures.

    I see. I'll keep the semantics for PERF_COUNT_SW_PAGE_FAULTS in the next
    version. Thanks for all the comments!

    --
    Peter Xu

    \
     
     \ /
      Last update: 2020-06-17 18:11    [W:4.168 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site