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 CB9C3C6FD18 for ; Tue, 18 Apr 2023 14:25:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C1158E0001; Tue, 18 Apr 2023 10:25:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 271086B0072; Tue, 18 Apr 2023 10:25:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 15FEC8E0001; Tue, 18 Apr 2023 10:25:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 07BEC6B0071 for ; Tue, 18 Apr 2023 10:25:51 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C253DA01A2 for ; Tue, 18 Apr 2023 14:25:50 +0000 (UTC) X-FDA: 80694735660.14.3AE9799 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf23.hostedemail.com (Postfix) with ESMTP id 86A8414001D for ; Tue, 18 Apr 2023 14:25:48 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=cpepIDGB; spf=none (imf23.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681827949; 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=acdTb2NF1xsomsKcnVfEiBbG+MTcG9TtMpBS+CWHSyM=; b=AeYmHXVnosRsa0GCtTXOShltUo0o1A/KyFls5N03A/g5wTHQmJlbdaq7BcDyOVhR/H7Qzb LnXDrP5XaqV6Evyab7jCw0oHrfRlFgc0QIhb//TGfMJd6QsbW00GRIUMI0T/4OiYs7zE62 Mk7GLHoqUnwz/e3ZhQyVNG7o6fourWQ= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=cpepIDGB; spf=none (imf23.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681827949; a=rsa-sha256; cv=none; b=opt9sQ7ODHlDIQlvRxhTGdId5eEGiHNlH0gRyDzyUIVzxlYin+Zi4PtKsAXQqKYZm1vqn0 hQvS9x+k9MPtJLsgGPlEGDvqHNrOpSybViXOTN7tafMbfX7d4yA10cJf952dKpGqkis86+ mF4jvT+YjTIq43IWUDOFXq4jw85kU5g= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=acdTb2NF1xsomsKcnVfEiBbG+MTcG9TtMpBS+CWHSyM=; b=cpepIDGBNWSNavrApuHseoenpD Ssapo/i5pSyMO/hK3yl/8G2cIXhMFprZOKpfqO3WSDCiAsjjlOVcQtYqAHaI139Rdpz2XDiHUhOeR Fv5PUKFFUmRT/bY98oLaf+qW3l1VVOwt27+zfkZ+1GwUmf/i1RbDeZ0b1hKEe/8hqfuENcUcOW8// uOMADHmAuSH3wqKLW1fLaoWusPqu6eFXvwnBAo8Ff9QLkKD03mEOEsHCWWGI3QxiyRbciJyOupVW/ 78wNJ8YCwQ6j11XvBKZ661T6QcjkUanXqPQ59W1NdekcBr9l7ldVufXXikTddXwNohkbFIjwMBDtj k3z5TXrQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pomGs-00CMbX-81; Tue, 18 Apr 2023 14:25:26 +0000 Date: Tue, 18 Apr 2023 15:25:26 +0100 From: Matthew Wilcox To: Suren Baghdasaryan 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 Subject: Re: [PATCH v2 1/1] mm: do not increment pgfault stats when page fault handler retries Message-ID: References: <20230415000818.1955007-1-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 86A8414001D X-Stat-Signature: wd6aq7wzct6t7d8bx4wap4ipuxo81u4r X-HE-Tag: 1681827948-825256 X-HE-Meta: U2FsdGVkX18dY9AlvRVDB8vYXMLyNqxcqZfG+OzS0Ha9v7cDIgMWV9NN1XK8dtBP1fO1sUn0YUlg/0fAOrSuaLTUGOKPGjoUEhkLvD51N67udyXCJoWH/CHuQgXyPiRVdaB4QeXFuKzax4zOOTbUXFqdu4WltkF9NEjMnqRDsRiuHwKF3mGiMiI0hPNRzTZXb9NcS7gZmckneQJ03lvXsKc6BOLzHuokWxmNTpM5CKZT/siSP6/4+1twfBwRUZkgpKPKX5BSg6YVjaMhIXHUY0gz3zVphy6RS2hb3msG7uPJJnZgZVCnOUA5/zO3DWs8PDfXjqpBQSVJyIkZfMdrHxeIroWtfoJk1v3M3bqEZRI7UVzEBLpeWrpwt07R4SfYw+sIdGXmOikOQacOvmyeMvM8gUbOkO6HN/wSYhMuUydhFmOblhaxxbk/NcI+6wUrubzuHYYaTPxDevTcYiTZqfuwBUP9z5Hu54UCUdCEabM24WswLjLXSm0XgHpJkD9XqM4LP0bruVNhBj5eUYCv+CRYQjtJmUdeL7SoythWDpsNPCBsZLQaLB45e3veH11IbUlfBVB5hNFx6kBnU1+5MMyHbWt6NQLA6JM+urWZqtbtLP9fE/kYJdshwmj9j3HJxVW5auekvf6eNaX4vPaPvgPWbrcwmnInHy5juX/Z9DTuhfxBverXmm02SwRsOefu9W+i+xanAqkcrNRus/SsyXPgBHfSgKpheG+K6aJvghTpSro30e5kIYP+w2mXz6kE4k7u/zJY0ExEFNTE/z7SB5S48MwREX4AHrk1WkoJmh9v58wS0JQAsaFlulB0KzdOmc/WU3UQevbBWhdC6G8KhZG6h8Yhv4gR6DCgiklNFaehw56cN048PthnR550AIOs5nY7v6/YOaaLkATR2CNLNVTD2bwPr/9SG7BnenAXFuW76ioh5ACdzzJerAJMjBqlLKfqIr1Fs4km5hjXM9D DS0hM+SV OjoUtfypzC1uGIgCqLckK8g0r8jk8ojzMdbLGbpvKYkEoeYGFhuay/6a02rkfalyDDVYrx3P0hw0P+PwrzRO3UFa/kiKEqCDk3mK0xYh1dzqzhvfS03ljFotvu24TjEKhkYLYj/LvON01LmcUSOsXyOVwe48cNU0txAHZN1iJBgOhTmZ5B+IudU7nUILapC8NEJSNCX/904aEsWuGWDbq0vrJ8w== 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 04:17:45PM -0700, Suren Baghdasaryan wrote: > On Mon, Apr 17, 2023 at 3:52 PM 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). That > > > > - * 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 counted > > > > - * once they're completed. > > > > + * Do not account for incomplete faults (VM_FAULT_RETRY). They will 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? Maybe I'm misunderstanding what you're proposing. I thought the proposal was to make neither ERROR nor RETRY increment the counters, but if the proposal is to make ERROR increment the perf counters instead, then that's cool with me.