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 EF2E8C77B78 for ; Tue, 18 Apr 2023 16:06:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7306F8E0002; Tue, 18 Apr 2023 12:06:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E0028E0001; Tue, 18 Apr 2023 12:06:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 55A788E0002; Tue, 18 Apr 2023 12:06:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 42F0A8E0001 for ; Tue, 18 Apr 2023 12:06:20 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1AD0940351 for ; Tue, 18 Apr 2023 16:06:20 +0000 (UTC) X-FDA: 80694988920.11.BD79A93 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 45738120008 for ; Tue, 18 Apr 2023 16:06:16 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=W+519f80; spf=pass (imf29.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681833976; 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=SH0/n2gRXAMCivoDkGd8b9iwO+Yl9rZdWUvZzMLaiXM=; b=3xwbzzppHWOJ2DuiE/zy7ynoGgQP+6Eb+hWJmCtnbGCSTNtQbfF8YqR9gFL1JlUr5CGG4R bHi1bwHJALvF6FyW0WdVAGLaOPzheO/JdritUF++YNubFr7il7NDC/alf5m876t2aoHFb0 XS54NfkA0XItCcSISWwLg7qsSCf4scs= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=W+519f80; spf=pass (imf29.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681833976; a=rsa-sha256; cv=none; b=cLl3PNuXyObWV3Ywd9ZGeRtdm2mghr80BFKy9zJAwMc3Dzje9Ak8FHg7+mg6X/su9jlVRL iWmoceHtxfe8Gqx1kx0l/QOW2sQdTrAoz07Ue1Ieui3fxTHyQQKUp7mb/wYP0FBMzhvOQL Bbxx1LRkp09ggdZgOB+9AnCNOWMsPss= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681833975; h=from:from: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; bh=SH0/n2gRXAMCivoDkGd8b9iwO+Yl9rZdWUvZzMLaiXM=; b=W+519f80bYyB9cFHeDD7oAh4cXfiBkLc+wbnoPwNnDO5KYTaxQLjaKOUgcOC0lCTQxgQi6 wU3NqoL2spUgrsy6uzzP3szYk0NFaHvYzA+FlqPD+16lGTKnavpp2NO16itpXmSEp2Of0N Ag4giOsRgApYEhsnBSAuC+x8mnzZBnU= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-94-ye5QQK-3PHCPHg9QPecUiA-1; Tue, 18 Apr 2023 12:06:14 -0400 X-MC-Unique: ye5QQK-3PHCPHg9QPecUiA-1 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-74deffa28efso14549285a.1 for ; Tue, 18 Apr 2023 09:06:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681833974; x=1684425974; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SH0/n2gRXAMCivoDkGd8b9iwO+Yl9rZdWUvZzMLaiXM=; b=C0jc9A/AlJWHtQZKPO+D6IrgMccAtx6msj7w0cpfR8rwF8/lrvusA5TxnfYHXj8HID cQZHOtfspWCwcFbP9S0i7yweDRruyMvrOTc1khOlDbjwnL+qgMaUe37sjGpKsV9C8WA1 QYjmFMG+A9hv+Lkzx9ZvbekBAJFR71j6uKqYuuXMbHrH6iRh9bmDditKoPZsGvFTLKg3 145Teeneq8G07ZLZwMwocGccAhIrpr4cxa98n/GbsQvCof3/bVAgf43vAcS7tDwmhKRF +0s7MmuDGzp+RPtfON2z5iUJ2N9MQauI7r/GAPJWQnejs3jo5V2tFejN2yKd3uhYTjfI eKWA== X-Gm-Message-State: AAQBX9fYxWVydWDugp1EVz2q6Oh1hnpvGSsjr0EX896YuzQOPidShk7Y aHg4wh1t90UxJZutwT1ts7Rpd1VAhk8VdcmY/9CxzlNp2+sH53T/x2RVAEqaY3nHlNC8/bidTzo +fJHgkuLu9bo= X-Received: by 2002:a05:6214:4002:b0:5aa:14b8:e935 with SMTP id kd2-20020a056214400200b005aa14b8e935mr21727579qvb.2.1681833973820; Tue, 18 Apr 2023 09:06:13 -0700 (PDT) X-Google-Smtp-Source: AKy350bDvo37hNrqe2q76IoGC5GeTPbTFWQEc2HzolNJM0oXlEltLJYo3iBGKgIMy77mY+7QV49Pyg== X-Received: by 2002:a05:6214:4002:b0:5aa:14b8:e935 with SMTP id kd2-20020a056214400200b005aa14b8e935mr21727546qvb.2.1681833973468; Tue, 18 Apr 2023 09:06:13 -0700 (PDT) Received: from x1n (bras-base-aurron9127w-grc-40-70-52-229-124.dsl.bell.ca. [70.52.229.124]) by smtp.gmail.com with ESMTPSA id f3-20020a05621400c300b005dd8b9345d3sm3786224qvs.107.2023.04.18.09.06.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Apr 2023 09:06:12 -0700 (PDT) Date: Tue, 18 Apr 2023 12:06:11 -0400 From: Peter Xu To: Matthew Wilcox Cc: Suren Baghdasaryan , 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 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 45738120008 X-Rspam-User: X-Stat-Signature: gjfdn5pnqoqc536rsaccubk5ysm9exs6 X-HE-Tag: 1681833976-662354 X-HE-Meta: U2FsdGVkX1+rnU4KB5BM59rwK806+K/1sdqKA1UKAo1RKXbNsp222h5XqXHFJ3KJA9sEVkrYTkgBw9YiczM+CDCMdt26rjb3ujNXwMsmPkNal+blniWCFvC/n5TgD0hOEBSwyR60MezuFwg3j/Ln22A4iYmD7j8nzvdoHo6s01I9jQ41/GBTigemcHbWyZUxysK4zQcjowjjnaP/Mcd9zt9rFTkMI4vPo04rZEyylJN7NhH+tLn9ZRP837M6dODCe6j5Xn+21IkP4D238P8GUHqdqr6FlhaqFz59TlMJHBdNKyR4rMW3stoXCWdNn8YYn1Gt5gKhlIiIDKoZqWhcVsRUnqYAGPgMpfkxYbyw9Lwe+r7N+Mi5BJe6KQFSX5LXaeM8Ls4svNOKBxEK2Y59RnLOu5wqSjtFbqD+yoPslWKNmOX00RIasmKfv5EoUOaQue8J87V0OmG4BC2pHHnClhfEmnMUovPOSkjt0t326ArAMRGUndkMsncElNW3adjZF4HMeVQoyYQl+xUpvzzGmCmrcqCFiX9qXc8f/rm3a+frxnmGNIPYaknGJ+P6AQlwRGIWIjP0irRr3rCGSoXPXfeTZj4zuQpKsizghKDRvVmQButzt0Hqp/1qhuU+TuGU/Vq6er4tvag4Bc3dA7Q3tBhcmcupvSXrQq9tsw53yXq5GYswk6SxUkFcZjWhGnVsJ62pyUpogjscRhUIVbecL7JrPya8kguV7ujKOKk27WagQWw7tjVXzPGWuSq8mRAkvhObYPNZoR9BD3Bs0j2HBBqYovEYQLxallEuo2ZvM4arVNKDQDkS39RgMw51/dRW7+zVrHfvb/QSFwNHX/frGVaJSPPlGwRHFPR/yIIem6VQ41sQhaLJepsaFSgaYF2aRVW4MwN9ZaSGrvINNEE72C6Xe7RqkQuA/dSgzZBXwCinD5pfHg/0MimIfhfX1w/T2E8Fdb50khGJSm0/C21 GRth1Fs2 BdzyKLYblus9p6r1Wnjv3PhrCQ4qK5Exqao8MwYFNWi6fparXKlaZ3/GeIwzgegDYFkE5Xpl9pIzxaS4ZdjhAWlfzewALuifoF9OjiSTJQ0ygjXUn+wp1Xbt8pbuPJUkY5Jcj1qGt9zRarg8HwJNOlMmmE9I07YdkXaWoHZ0ZO4mYDWWblg8idIdlCWjdY1PrI/Tym4k+OoQRSRRDAQNzgxC+7gcpOfTcCguA/n+7UmhAzTuKGEsj3g6zn3WUOmkI6HP986SjWfKpi+d0cqUuOyLPqteMgGs1qC2aowbGqWMPIoXREJKHO9GtwNYXEH7Am7uOmme0WAiIZga+MX8cf/n6n7Vzht3ydUbN76dqmV2Dbzce52zx4GHjqJLVwXlAJ1GYg5YlP5oA2nLgW+sJJy2uQWf/8EVI4xjACduHNTKo5S1HaTooRt/0BcjLKi/BUNytI3qOe8+UFNwF8lDRTeKCzYWEzI5DXzKs 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 04:08:58PM +0100, Matthew Wilcox wrote: > 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 ;-) IMHO if there's no explicit reason to differenciate the events, we should always account them the same way for vm,perf,... either with ERROR accounted or not. I am not sure whether accounting ERROR faults would matter for a mprotect() use case, because they shouldn't rely on the counter to work but the SIGBUS itself to be generated on page accesses with the sighandler doing work. One trivial benefit of keep accounting ERROR is we only need to modify vm account ABI so both RETRY & ERROR will be adjusted to match perf,task counters. OTOH we can also change all to take ERROR into account, but then we're modifying ABI for all counters. -- Peter Xu