From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50A32C77B71 for ; Sat, 15 Apr 2023 00:11:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A7EC3900003; Fri, 14 Apr 2023 20:11:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A2DA8900002; Fri, 14 Apr 2023 20:11:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F499900003; Fri, 14 Apr 2023 20:11:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7CB03900002 for ; Fri, 14 Apr 2023 20:11:39 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 39430ABB70 for ; Sat, 15 Apr 2023 00:11:39 +0000 (UTC) X-FDA: 80681696718.12.7333CCA Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) by imf17.hostedemail.com (Postfix) with ESMTP id 7A9824000E for ; Sat, 15 Apr 2023 00:11:37 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=zdoB0mdU; spf=pass (imf17.hostedemail.com: domain of surenb@google.com designates 209.85.128.172 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681517497; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pkqxULQtn4DIJOtRxa3hlJU5+U6gyzkzztKjrzetxVg=; b=YtKd7Wa4bQY/D0KuWiAvTpzPjngchSfK2WuOaLJmhzN4WqXudjSXP/QrK5KzDuQoiJaBv+ pPJacwsm+Azb8RwaOZRTos5yGQ1yFgJdYxlT0z85xMH7NZChDHR3I9n+LCscD2vjytosom ICJY3Di6/ff0SQkTOir0PItgrV+SjvI= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=zdoB0mdU; spf=pass (imf17.hostedemail.com: domain of surenb@google.com designates 209.85.128.172 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681517497; a=rsa-sha256; cv=none; b=xdkc0v/fAiHnHS8cPVcs7FARMwUDYIS/ucFlfiPf1ibyCRH1ON99ZFYf292XLx+37hUYMK EfCBYJyl+s5T7K59xMIAGurLTBBElJDLHlaPcXE6dZkB/nyLMNXAbV0qiWQqw5YfybVZRX 7eK92TYKvuyaiy91uvlimSl+eiVOiMs= Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-54fbb713301so128214567b3.11 for ; Fri, 14 Apr 2023 17:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681517496; x=1684109496; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pkqxULQtn4DIJOtRxa3hlJU5+U6gyzkzztKjrzetxVg=; b=zdoB0mdUNyfPlFSNxAx/BADkB/3lor90AD9J36jsD506YnwDQWWxHmVMDjws2daMHm xXN42LbjEO3t8Y0mdMJLK0+W50JgJ06UG6ouln0nlkugLeWkGLowddhz45VWNTv2sv2u 2bdafVDN5DFrD7sX6TfV1hVvhd0q0agKiuoPn5000fFv96HM+Jo1IG3XgJsA0uc00IwF 5Te/cZRyGJLej0wx8ytcXdLA6WpQl1mUVbbwXWW1eNCXRkFB279QcpvBDwZFicpKFLBq mrWDDLaeWD8T+qEnXDzDhoeJJucJ5hoyjuAWixt+UAYuExU2N9udfHYtZO7T1Q+TNSvs 3vLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681517496; x=1684109496; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pkqxULQtn4DIJOtRxa3hlJU5+U6gyzkzztKjrzetxVg=; b=Tld1HrQMaEIlDtazy3YE58ais/6U5U++JDb23A6gu5abdj1DIgvuN/h+QNhDE8014P AwhkY0HunmDWM+c6QguRFx2zswQ1piKu4k9WkVz7/0/P6HE41c/bZf3bdR2ELfoc0cC2 Rl+luzOvdm0ajH172i/zrFu48DQY+l7+nTvzVkgAVUqT6jmCtJo2I9360MgafsGLbGx9 fsb6gYyJJ+n8TPTX37ilfnyjDBn+U+NDjOrdwzQ3e6zO0PkSBI4XiS7LzkOEqp2VDnu9 27VAuvv+iZwws0BJTe6TPoTI8qJauC95JzmbmfXwalTXV9a7UdJf6uBrO0iLo2WXRZPD 4HXw== X-Gm-Message-State: AAQBX9d2vB+VeiPC0UL6ktbzefFVNT3GneZqzAbG/PgQwUEwJdaKRMDw W7ro7vLb863MfYr12NkEepyszdewh5fTLemY2Nm1yg== X-Google-Smtp-Source: AKy350bXqXiGeg20GRVRaHp2m6a8mhdFkoYmH1mDor76YCRhrh44NmwQi4o+xPPJ0nIgpV3b9dvxqvWA6P+uaDqiNVs= X-Received: by 2002:a81:d441:0:b0:54f:a60c:12eb with SMTP id g1-20020a81d441000000b0054fa60c12ebmr4685300ywl.1.1681517496387; Fri, 14 Apr 2023 17:11:36 -0700 (PDT) MIME-Version: 1.0 References: <20230414175444.1837474-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 14 Apr 2023 17:11:25 -0700 Message-ID: Subject: Re: [PATCH 1/1] mm: do not increment pgfault stats when page fault handler retries To: Peter Xu Cc: akpm@linux-foundation.org, willy@infradead.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 X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7A9824000E X-Stat-Signature: guujwiyf63qeprxpy1fn5izex11ruhy7 X-HE-Tag: 1681517497-708908 X-HE-Meta: U2FsdGVkX1+E3hBBdcX4s1hxzHRwaW90m+9bp0SYAwVqaSgigzCy65XXqB2sWBdllUDTbRwut9vnvIYWazAaGPgKaO6z3OQfGVb23Mj6us7oy/1VNzu67jwBrzHQ53onZY8S58Yis05uKE8lPtLT6xWyjQMPqXOoeKmS9nI8eBX1qb4SeogChgjsGFScvlpVlMZ12Kml6BovK4GGZbPPGtvsds7/wh7R4uZSKZ79KTc36hlTWw2sDQXztBJSGi1PxWCFm5g18udMVVQMTlqcex5yoSx/Gt6/maJZwYsshysBNoZ1tmElMGMteLh3S0jB3tehRLGn7tBqvmGTbQalSyN8uaMyBSkbWw2XBBWf4MkUsLL28ykzRpqLI4+YRpsEPeV1DAeMKTr9bueeXSljIzU+z/CEbfUNZAM7CbjrczRvuAFm774yPTSQbBkO2I1dcd+4vKrLc0IEnL2OWbrsq/uXVoZeX/v6k/sfd2REDSGw6haTA/8AppzNd/J43/uC9IHItNeDOV35QPiXTUd7wfmEY0PYFR5OHpRUNDnjdkZgPsazZvp8VBsjI2ds90Wmlxbahp2hgdZnkTO+Eny3UEXZ8VbpYua8rpmyxX43mONoJAXE2AsrhJ7LUq2uH2D2nEXHtKeMpgtaUWqM7gJh+Q1f1oLQKmTDVz7frt6UCsFRAzzU2xYPcsGqkq6BYLnYBp9BkmmOcFS4qhCVTOBCq7Emow6sEgPMdsIuwtut2fvlmByhNFRuqnGah5E8pvzAZWf9E13XGR7ydTMvqTFQ/eqfwHI81DYrzXTLGg6O2gEz295IwCBY2T4HqcevfSm1VDYQhVR1HLFNthLL/GVzqFCoyS6sPLaNeeVssnbYuPOJUD74jQMXenL9uA8gh7Lx/QUfOOgNZEfwNe1EE6j1q5YnXzN+b/ZyVyBFmwYmP3wzTEn+Vlxbhi34VEoethLkJqhYczu8An/z/FSeZaI +xA3s/mV kPBc9EqDLYUP+iK+0n1u+2ZNypCQ/Vv6osGyjvuncp+IqjFG8ZvhQBT6Egq0CTnmdHKkSr09o6vKnfuIELHLShS2yQWJkvJG2GDx4JU9+loZrsrkNJ9R+KN2k55/Mwwawi5ebOy/saNg/KIDIcjXOAHGhrlJDJmg2XegZFUQ9hD3OQHaBMm8QN+t8bNawI2Dv6haZNFKoMqjbRRPDk897fuKfPiscqS4rDMz1wd4SUiRB+cMJQaUM9kaQeNvjPQJ/Xiy2jIIQ46cyOxJzQiT9z10xX+AoNgIJgrcgvQRx3QU2mCHHhqNbLYSsgDydsEVtfH8IO77lr/rUWRaT6l6JyZi6sxbEw3vJlaRy X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Apr 14, 2023 at 4:49=E2=80=AFPM Suren Baghdasaryan wrote: > > On Fri, Apr 14, 2023 at 3:35=E2=80=AFPM Peter Xu wrot= e: > > > > Hi, Suren, > > > > On Fri, Apr 14, 2023 at 03:14:23PM -0700, Suren Baghdasaryan wrote: > > > > It also already ignores invalid faults: > > > > > > > > if (ret & (VM_FAULT_ERROR | VM_FAULT_RETRY)) > > > > return; > > > > > > Can there be a case of (!VM_FAULT_ERROR && VM_FAULT_RETRY) - basicall= y > > > we need to retry but no errors happened? If so then this condition > > > would double-count pagefaults in such cases. > > > > If ret=3D=3DVM_FAULT_RETRY it should return here already, so I assume > > mm_account_fault() itself is fine regarding fault retries? > > > > Note that I think "ret & (VM_FAULT_ERROR | VM_FAULT_RETRY)" above means > > "either ERROR or RETRY we'll skip the accounting". > > > > IMHO we should have 3 cases here: > > > > - ERROR && !RETRY > > error triggered of any kind > > > > - RETRY && !ERROR > > we need to try one more time > > > > - !RETRY && !ERROR > > we finished the fault > > After looking some more into mm_account_fault(), I think it would be > fine to count the faults which produced errors. IIUC these counters > represent the total number of faults, not the number of valid and > successful faults. If so then I think simply using VM_FAULT_RETRY > should be ok without considering all possible combinations. WDYT? I posted v2 at https://lore.kernel.org/all/20230415000818.1955007-1-surenb@= google.com/ Hopefully it's closer to what we want it to be. > > > > > I don't think ERROR & RETRY can even be set at the same time so I assum= e > > there's no option 4) - a RETRY should imply no ERROR already, even thou= gh > > it's still incomplete so need another attempt. > > > > Thanks, > > > > -- > > Peter Xu > >