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 AC0C2C77B76 for ; Fri, 14 Apr 2023 23:49:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 26E9E6B0078; Fri, 14 Apr 2023 19:49:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 21EE3900003; Fri, 14 Apr 2023 19:49:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10D27900002; Fri, 14 Apr 2023 19:49:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 038E06B0078 for ; Fri, 14 Apr 2023 19:49:34 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C0389404BE for ; Fri, 14 Apr 2023 23:49:33 +0000 (UTC) X-FDA: 80681641026.23.5C326F0 Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) by imf12.hostedemail.com (Postfix) with ESMTP id 0CAEF40004 for ; Fri, 14 Apr 2023 23:49:31 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="Y/0uIWDs"; spf=pass (imf12.hostedemail.com: domain of surenb@google.com designates 209.85.128.173 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=1681516172; 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=No46jFhwGzkRNUpDWHs00ERh1TJYKH/sOU4hg7TOFIE=; b=Ld6MPjXP1H/YE2JtzUvUpha6ompTVnH5yAr2YiYU9soQPR0Z+WjnISGTVSXIM+gBPkTYxG gkbpfJ/gHTNZqsPwuiM5UM07u0N77bRF8rRVZW1qNJ2w6zUTqgt7tbkUa0UyIuySxskwXG pyIDJkDMZz+55a8rs6ZVVAHH2TYfRA0= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="Y/0uIWDs"; spf=pass (imf12.hostedemail.com: domain of surenb@google.com designates 209.85.128.173 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=1681516172; a=rsa-sha256; cv=none; b=Qz1/Kb+tUqsZvgcqeKdjNDrsYcfyeBROGvYNLqHctQj/BYnWFd/1C1DlHLe+EsJ9f/eO5G ZXluC37adOlB1nii7G/CvM0SLOP9v+WBKkesHsk5tzG47ANZARpC34CLtoUB8Qwnt8k6Dl mCcJxPijRNPmlDFTuW/PL8J/lZkjJfA= Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-54fbb713301so127906167b3.11 for ; Fri, 14 Apr 2023 16:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681516171; x=1684108171; 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=No46jFhwGzkRNUpDWHs00ERh1TJYKH/sOU4hg7TOFIE=; b=Y/0uIWDs7JruwuGPhftvVUvAzBHjysvv1C0uwnnnVgunNCWugJF0fxx/j8VtpL3PC7 9BXu7sZfji0Pu6jLEcV/0u29Xo1y2q1nj0v/aNx3D/ypJm9uYLeZF9jXSsvWJdUBYspV 673r1xgprfwfvd6GClwVeNSByKcn6KXpd9QvzA0L5jMD5f4c/VAOJuCL/tiQvGkONU0s RgNUrvI9FzV6Xx2agJunBEoHwNpTHpKkHtVgH0itjcK/lrCwUK36Zd0VHREE40zNJd4v dFNu7TbC2ag8TlFU5sPT5DKIJV3d5ifyvVGn+4PjLrRDzpaLjo5fUK/3uFUA7gViZyDe cBaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681516171; x=1684108171; 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=No46jFhwGzkRNUpDWHs00ERh1TJYKH/sOU4hg7TOFIE=; b=IHjOLaubHBS7ZovIQ8ItpREGOy2M08x4OFbtrvRtldAfwvkuDLJClj1Kd/u63dyqMR DSOqPgvg/S1DohCh6KuXqkxaj08avS1l51KIdoOH3pNHys25UpNVTQcH+z/aWwENSFVL GM1JI5oRVx/u41VmkHiTpJyXG7xFE426KU87Mdnoo5b2++szDwgk9hkCa4TvP0kWqNui XXnz91tkjvZE+srztNB37S/IOjYk095v4smnRtMyrtDM/CFgYdyp2nsIpI/2JRHNT50g xgcE6rCuSa9paVCyPYJlPmtJtCr1hUeMUGEWg7AoeymYVm+fv9M2GmsdFbZvEKqeaYyf SBgQ== X-Gm-Message-State: AAQBX9fXv3UaihfrWzcmeIEr/FHv/lX6k+UKVtipTdIrPnQQ6Pi0S50/ 41wjGSyggve0EKNZmrkQRxLJBEpRunXxewaT6QfT+g== X-Google-Smtp-Source: AKy350bSj1CSWDY36bOsJSsoidHfrQ6bQV1QcvO4pqangbXIyw9XYy4patdK5PqOcIhIsOqfrXxeZSv8RhGW+y1n/iA= X-Received: by 2002:a81:af0c:0:b0:54f:8566:495 with SMTP id n12-20020a81af0c000000b0054f85660495mr4919497ywh.1.1681516170910; Fri, 14 Apr 2023 16:49:30 -0700 (PDT) MIME-Version: 1.0 References: <20230414175444.1837474-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 14 Apr 2023 16:49:19 -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-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 0CAEF40004 X-Rspam-User: X-Stat-Signature: unhe6495mxeb6jfs55ttp71k5w48zyfm X-HE-Tag: 1681516171-547738 X-HE-Meta: U2FsdGVkX1/BxbLnMbcOWrvmg2j9hXJel/Y6CJbdCKhxyyC+dKoVb89753M2vCT0PGkUR+5I0OYoVMbmfngQmQA0XMTq3HVtt3PKqQRVvHdia+a3H1eDCbHHWoTq8sC0fOJAWqR+ZJleHF+5HGPQdKLi04rMNLzV3ur3OtgL6KIDueJ6QcTwdMU5naFM3hHKwymAUFPzOmQq/8CZyx1ucl1aKufUP1NPgcpKVetoFOMUYSaNDOnz72Q7UixcpzJDm2nQptNmJWhF2ZjD9zxUnjhUdXOof9EVt4wK8+57Ev3WxWveaSz4GBQz1ul+IQHwK82jI6Y/nzQtk343rmSmBNXo0b6ygFC954oID7Wt6F50XZHGa78Q18TEyHU0UmrNMOAuwQzO9gH2v2xbxf4YYmpOdHlRv6+4OFiGtzYpvV5wqzA0CDp2Wm4tTdpw4OPjWV+lvsU/mlXXb1iy0Gv9AIW6MABvSNewzIWgSlO8PT9582NqmVR19w2atpoYv7A+atPUWbRy2KLJo3aXmIfGvQea6ytAZ7aQLwnftCLxEIhKwaUmGQJ+WMIHDSZa1SzhUE5J3NsOVhRUV5taMUhKiIvy+1VvSsvHdlYjOPILfWa1s8P9q0sCjT6yO5hczj+1RpYAlWQLU5XNpbmqXa++BnlMvmGLYgGwkMoj1yQvCWmh7Shrb2RoQrvOJ50jEQvbzrOq9/dQtHr7uF4gIDbCoLK2UxpXPdUEwbwt6qaxUV068wcK3XgFwDCXCzIJqOKfs8yQs1JPzwF9zsi+A3cqPzRHTu0E/IE9gnD3xEHnLlPmKqlK8qLsk3cHZxrn4VNXzRehdMuxQCwsDjn8fkmV7KoxyrVjtiGVFWldqfett8C5kIc5h7KemDdt5LwPAMfNoHd2zMx5y5TwicVAy2nKIzQoa1ohqiUgzKtheZUkeFgSqMPltMSoBFJzYqnvJoKVyhuqP9uk7LQNOjCHQ4Q 1AD4+YcC ubnqpyVZCh3lEyO94XwNZ3d47q/qvPJN0VqSyD+pICMOP4wN23Lm+z1pHdgaco4b3Q6fr21xQiZo4mFQHCc2cawxbzpc/f5CT8rHo8NX5wyKauN80FhD6urBeYj9V3Dm1fs6+Lz39YinfeWw9EB0bwbO7oZRr1iHxeR84V5c6a7taN+YJAJgPFFu22whOuBIvvK3h7xZG4u2py+ZjzdstMcXPhUHUXlCuDQxcCMRpqtIHlVbN4ugD24SA/GTTjNepED9wBFT9odwd9+Y= X-Bogosity: Ham, tests=bogofilter, spamicity=0.001260, 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 3:35=E2=80=AFPM Peter Xu wrote: > > 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) - basically > > 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 don't think ERROR & RETRY can even be set at the same time so I assume > there's no option 4) - a RETRY should imply no ERROR already, even though > it's still incomplete so need another attempt. > > Thanks, > > -- > Peter Xu >