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 A79C9C77B75 for ; Mon, 17 Apr 2023 23:18:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D3F3D6B0071; Mon, 17 Apr 2023 19:17:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CC8828E0002; Mon, 17 Apr 2023 19:17:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B68BC8E0001; Mon, 17 Apr 2023 19:17:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A354A6B0071 for ; Mon, 17 Apr 2023 19:17:59 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 647BB12047A for ; Mon, 17 Apr 2023 23:17:59 +0000 (UTC) X-FDA: 80692447878.13.A7E0779 Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) by imf15.hostedemail.com (Postfix) with ESMTP id AA88FA000A for ; Mon, 17 Apr 2023 23:17:57 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=XFhs4lbT; spf=pass (imf15.hostedemail.com: domain of surenb@google.com designates 209.85.128.182 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=1681773477; 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=P7sqT2MMNV6p6hOax3PoPR+0asBKqco8uuNCkq2LhVM=; b=hmMJu9fTNK1udGkV8fsit04897BPkMDBrrVU9p2bQTbP2qjjEw8WU+HIlg6NMrG8fOAy2X UsaSMXxriS9rBGYfN0rzmDm7qpVp7j3E65NJ/qfUGJYsxoPLjcmvpmkZO+sA/d7OM7f4MK LsTQ+YhBRokdmzyAcg8QrOBE0HLQxSs= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=XFhs4lbT; spf=pass (imf15.hostedemail.com: domain of surenb@google.com designates 209.85.128.182 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=1681773477; a=rsa-sha256; cv=none; b=S2L9CIMoLKPVnRt5eVJaL/k7RObWHpkEGDXCE5WXQLoY6+OVWajhJvziq7I7N6jvRSc68Z j52+8LdJYhwGjxtzSsZsOmtR1h5GHd0MS//6ZtEuH4W9qks7AvCrEoWl4lqZh7bdBZv0gO Y3/JPojUvJNm8csSaegH+PVrN9vpfGQ= Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-54f21cdfadbso385434677b3.7 for ; Mon, 17 Apr 2023 16:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681773477; x=1684365477; 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=P7sqT2MMNV6p6hOax3PoPR+0asBKqco8uuNCkq2LhVM=; b=XFhs4lbTpFBkCbCXvQgW2oHC5DWbyjcxDrzxy6sUo++VgawktEiOJALIBFGSjXar1u dIP4YXahmH0tn11zBHVHQ49Gp5gjfovqSQ/Sz1gsKEM7ENStkLmat84xQhyzk0E88z50 0G24fj2YYeJlDbHkj7M5Omk8UDuV1lh1rjciHXC7oCkk7DuhQSXgoQ4z8lwa0B5zUixJ jggcH6zEHhkXFQeV3F2WvY8OTOqzB5LmfqR9ziz8WoltWMPovWPFQ9mFxaSQW1r4ERtN JuWxZtlaxKp4zLLDCTFB4zcF4pDUnhcLmVMwck67DGOsH0gdPGuUQ+eu/ljmq6Q9hB+7 9LUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681773477; x=1684365477; 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=P7sqT2MMNV6p6hOax3PoPR+0asBKqco8uuNCkq2LhVM=; b=h5LR2a/uQ7PATJjRp2Wkbr9QIr/yaOau/f1tQUv4Rqlw03AgTptc4eE9LAiaU1V+h5 eE1P01pxI5w7GgodlNVDvvE+GgIlREzgBjhfCxrwOOhY1VWRCs2ysCpMm7B9Yjx5jtGl o7jr3KEHJzQ95Q5cZoojGP+q2yh2qLBbAjOBlIRYUHslZkKjeFQWzczfuSJ5tngb/VDq Dr5zCFwt4OK0WWieN16QgBM0RATduyTiBXuVDS3RSYXq2zu3rQkLW+LWqD1qaT6pTnuI DisNfMDqpftIZeh5xGyr1PM0E23BTjz93+rhcX/oMzyGJgRNmtBmXFky7eEmKzsgbNR5 JEWw== X-Gm-Message-State: AAQBX9d4KIE1+e5oJhfI9HUtPbI/MF3/fPHVHJoNjf4ZPKFxrsU95G+c 8+SZVZ1cD3qOzJH+AYxTLi9bhFt6EEl7QG0ktUKkHw== X-Google-Smtp-Source: AKy350Ys7h+H3UG23FGfVDvHzrLubQ22gurK633DoVg7WxBxFbRZVhPMVLAweNPk4OvxDfUC5hTQxjRgEPRMzBJNeQw= X-Received: by 2002:a81:4415:0:b0:54f:9e1b:971c with SMTP id r21-20020a814415000000b0054f9e1b971cmr10701230ywa.1.1681773476678; Mon, 17 Apr 2023 16:17:56 -0700 (PDT) MIME-Version: 1.0 References: <20230415000818.1955007-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Mon, 17 Apr 2023 16:17:45 -0700 Message-ID: Subject: Re: [PATCH v2 1/1] mm: do not increment pgfault stats when page fault handler retries To: Matthew Wilcox Cc: Peter Xu , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: AA88FA000A X-Rspam-User: X-Stat-Signature: udgwwnoue4mn36jofe5ixwpkg5why3bf X-HE-Tag: 1681773477-33210 X-HE-Meta: U2FsdGVkX18G579dL+wb3Rz0FIUvGbY5vPDwfhBpb/+HO7qyS/ykuAKzG6NyjRFvAYW8oiUIJ6RRmCWMBWrmfU/5cx9d/un5Oymnhv0SNH9IzE70DH7pLoO+gSNEqcxF7+FZal9fvef2jeb8ijWOWyjTQLyldcyWMKNErowvV565tOwJAUpKjpmZMfkHqDsytaCpLGwIlrbLUrDnu+29uG1ZaeHZQx3/AcxSEKReim4NKa6pAqteW5L/OZIsRRpMPo2AEAJsjo7iIQHWvnUqzrT5qbWsXKlk+2Il8iesQHXBsKHeGMW+Bhtj1CgSrMCibqYHXgv+oyGYl7XyrSfyh3FitMeOYBKoD4A47H0P7iDzB9wALEZcHWbIHzMrxhMLVmulzk5NnZljHRjEgpTmq2rjJWTC+KGNX1h98LH+jKFDOygZ9u4kV9tnw/zgvSXxTMMsHjHSHuC3nvE8sTQ9cJRaUTZ+0z1WcYQ1yByTvCfs5XK8bWlFxKGYPLZRBTrt9Mpy398H1XlaZ6X9nT0143j8i6ycSzsVINf8qPAwEOBqVl0uq8vCAz4LyToMA1T515T8rKRaky1LjoLtT6qXokaBuoZBUm3iU2m7ErGbcaEFAkTgtVt2A15tMoszKXA5xAeinoeDbjvL/1FyYeuoMxmz53NHzxNnlrw6IesVneBT9nEbxw6beAmQirK3EH6DxNyQ4e0QUYyk/ExQFPllyoZudMYo/e5ff0C6eJn9H/ZcAWCT8+LQTsnb+KMu7LGgxcQxDD8TtnzCkH1NOcUzV9N277QN0GNU84astmB+tuVk4K1zCGauVJxCTPxUL4OBoSvUvDL9kzcBt5W4sKvmJev+RlVFbyERWFDrhn1bD73x5ZIupm6ul/Y1Lz4fCXzM95NjRU06MOSaa+6KnzmtxBlKy682lD3jprNdVb9swDneztR+QPvuZA6Hq+VWuWjMJ9RC3Xzj3q9Ay3+73ne VWOrxe1h JtnLJOMWMiD7gl7tCuvhFv3RA6C7+zgQ46r4kshKSD/sc/MMC2XWWekJHttQfqMdOdi4ftfs+gt5Ce3fo1K6XcbLtmGpfsQ1yZqTUGVFIPuXM1c6Yh68isPxMPgTQXU+FP7KNm1dZAMnvV+VaJpGcWTOZtQ3N80MZ2o5wI2XEQLjqjHjHUskgeMP3MNwBZe4X3T0J4dO92qzjHWtkByBVJKQU6mya308gMAeDKfZwAG798v9xI3ut7pxKAeHdxWyxFpdR3q++2lsErjE/BFmfKR91a5KuKGHKaMd+TZwelEvcWMlJfYBrMOhfSw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Apr 17, 2023 at 3:52=E2=80=AFPM Matthew Wilcox 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). T= hat > > > - * 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 count= ed > > > - * once they're completed. > > > + * Do not account for incomplete faults (VM_FAULT_RETRY). They wi= ll 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? >