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 87C5DC6FD18 for ; Tue, 18 Apr 2023 15:09:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AEE8F8E0002; Tue, 18 Apr 2023 11:09:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A781D8E0001; Tue, 18 Apr 2023 11:09:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 918A88E0002; Tue, 18 Apr 2023 11:09:29 -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 824BB8E0001 for ; Tue, 18 Apr 2023 11:09:29 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0B69880322 for ; Tue, 18 Apr 2023 15:09:29 +0000 (UTC) X-FDA: 80694845658.02.120D90B Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf09.hostedemail.com (Postfix) with ESMTP id C4791140013 for ; Tue, 18 Apr 2023 15:09:22 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=C+Z2qKcz; spf=none (imf09.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=1681830564; a=rsa-sha256; cv=none; b=lHU1+z7KnQtl5WI+DqSnvN8UxZ5U6bNHxskzJYs70/evCJ5jUOuqEaFPCXwwKeLBYHIK2W KYQnqvjsW6Gw1ZjbbNRQiHZ0trYyMEolvn/gN+k0LcNBP5IsTJclWbHM9mPmazRdnv4Qrt 7oqvTS3R363VDnCUhi7s8lbmXPmRjV8= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=C+Z2qKcz; spf=none (imf09.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=1681830564; 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=8yOGpdRF4UCqqQfqFDrE2rgMF8gNHIdalLte7kmTZ4E=; b=zqD9mmzB9bko10UUCHwZlk101lsUlBnmQ6m0slf7pAB0kgrCiRxGZr5IY4bs+9B13o2FFI 9cshoUkccQc1t1BdeiM82rnmXs+d5fDfzxoLBQmQbFEJkZIuuwIY7OBchsovcJCoJJyp8Y ifcFZMhZMn+GnBbHe05cRhmhAbuCS88= 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=8yOGpdRF4UCqqQfqFDrE2rgMF8gNHIdalLte7kmTZ4E=; b=C+Z2qKczB8op70IFq+kz0Og7Ak Cb1CZeP4mu8+k7nhUnyW9Ts7AjzlKFrscW2HrctkFvS0ljy/ATzznsvfE+yCVF0uEr02pFqZIzb+B +jSpdzagz36KlmjEIzuY7wDVcKXwb97SUlLq+cPSfRM6mVz4cFw5EV/klQHikKPxuVFMYKdpxafRK 8rSRw4TCkWq8osMhX3LD9T3HVIcDkQu8psQeXNZ3EoWqHD8jGOGI/jdtuzoy1nk4V7CIhhuhVR02r lCvqWH7XXkK+BY5VkFK/NxWPRLoOaK1MVuPjFRsYEUcI/7+X4CKXdvbnsw4ST9qAaLX94qIk2VVIQ 4h1Qsx9A==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pomx0-00COUG-Cx; Tue, 18 Apr 2023 15:08:58 +0000 Date: Tue, 18 Apr 2023 16:08:58 +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-Queue-Id: C4791140013 X-Rspamd-Server: rspam01 X-Stat-Signature: o1gbbediy9gx5k8czptcacd81cnnu8an X-HE-Tag: 1681830562-624944 X-HE-Meta: U2FsdGVkX18T31VEX7AcXgWJMBWHr/tKFqM9hOUgiD9PWzICOVenKFZL+8m4e3RFpXZ0CoELXbDe54NDKr2Y7nZUo8TJ1eYTavhvIRPpQyYRC51UufeJRBkuHQWq76J2K03tUr/j9UFIZPKPGA7GS5UJu8gEoAfUq3LwjPEk4kJSZ1SXUFLVEvB+iCnMYNJVSVSZQZMKirqw+EO7pKWXRyNCrpOHrNaJCpE4pIE9I1fAqs6fIDqMW9SM3+roknizwHBnr2diNl41fimpAedkSWtBQzSGc4D1NiyJxCPR4VoZHkgN7Sla5p/iXKGqPOB5ZRBY7m3hq5pA0gOsWwAcXNtMxesneZNf7goLj90CRIZNMMyq2EkpZG49ff4OB9GaQYvLp4UEHvJToESurkJIrlA/udd/5yBfHluBV+FvgJ18vWj9LIEmhXyne7FJGryKVimgVshgTpF+KDfB9LRbbJeDwCLHkMSAJsRVNrnUmiIqsscsdYNtyS2trLjZF5dw4LDezM9Mt9I+7Ls96LSDu/gSpaInuYYYIJ4Fx0zlcmLJQPRjMgBF6wlJupQDAdWFhPioFS05WyZ+f4CyiTWQiWJbcIjcaWMfArGyMX7K0OR7li2n8/knarrbMJN4OBgqlVqo2sDQfUvTtK/zDnH2q4umDWX89QmFkJVrqzp7SExs2NAHGBd97z9TvYhGBe4wRXtw8vBdGVMGJf0ATN1LS8Vz/qLUqOKe2ys1yDcySpJq50/d+CZDOMeSCjZiBVEbR5jQjbhYDeHnmzAH+o0p4Kz78aS6ziVBoHpAViWGAoHZpIb1w0eLdNBMbCOW44C8zKNWYvStXYd+ax02z3EgdCd5vd5wcLdyEOqG8Y/ymQzGPf/zIyP5jFef6mvAOURGTifHqWEDMECnTiq32ujpPlIxw09HupFdTKOhh9lIy6Te8ABnOlkPtM+TZBzzAwO80EpCP+cDAMlU+q/1HE5 ZE4pW3n5 FhpXH4IkTzthZbp7l/Mft5eCiXtTvP/Hdtzg9i5BXxGiyuTQbbSf8WFlOR3HhF0RW7xqS29QivCa1447zNrWcUJxbC0pLSVLcNwFqEQQDmDjPDa5/MGQ0oQktZ4CXlf2wqesoiiz7rqYIuNWck6H67QZyFKhV07F3n3+RFO/TyyVJmN75ijVzrQkjMLMjvcj7YCn/biS5CHeYwUBTbCHGDt5a5Q== 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 Tue, Apr 18, 2023 at 07:54:01AM -0700, Suren Baghdasaryan wrote: > On Tue, Apr 18, 2023 at 7:25 AM Matthew Wilcox wrote: > > > > 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. > > Oh, I think now I understand your answer. You were not highlighting > the difference between the who but objecting to the proposal of not > counting both ERROR and RETRY. Am I on the same page now? I think so. Let's see your patch and then we can be sure we're talking about the same thing ;-)