lkml.org 
[lkml]   [2020]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 19/25] mm/s390: Use mm_fault_accounting()
Hi, Alexander,

On Tue, Jun 16, 2020 at 05:59:33PM +0200, Alexander Gordeev wrote:
> > @@ -489,21 +489,7 @@ static inline vm_fault_t do_exception(struct pt_regs *regs, int access)
> > if (unlikely(fault & VM_FAULT_ERROR))
> > goto out_up;
> >
> > - /*
> > - * Major/minor page fault accounting is only done on the
> > - * initial attempt. If we go through a retry, it is extremely
> > - * likely that the page will be found in page cache at that point.
> > - */
> > if (flags & FAULT_FLAG_ALLOW_RETRY) {
> > - if (fault & VM_FAULT_MAJOR) {
> > - tsk->maj_flt++;
> > - perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MAJ, 1,
> > - regs, address);
> > - } else {
> > - tsk->min_flt++;
> > - perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MIN, 1,
> > - regs, address);
> > - }
> > if (fault & VM_FAULT_RETRY) {
> > if (IS_ENABLED(CONFIG_PGSTE) && gmap &&
> > (flags & FAULT_FLAG_RETRY_NOWAIT)) {
>
> Seems like the call to mm_fault_accounting() will be missed if
> we entered here with FAULT_FLAG_RETRY_NOWAIT flag set, since it
> jumps to "out_up"...

This is true as a functional change. However that also means that we've got a
VM_FAULT_RETRY, which hints that this fault has been requested to retry rather
than handled correctly (for instance, due to some try_lock failed during the
fault process).

To me, that case should not be counted as a page fault at all? Or we might get
the same duplicated accounting when the page fault retried from a higher stack.

Thanks,

--
Peter Xu

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