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 CC574C6FD1F for ; Thu, 21 Mar 2024 17:23:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 630AC6B00A6; Thu, 21 Mar 2024 13:23:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E0FE6B00A7; Thu, 21 Mar 2024 13:23:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 480EA6B00A8; Thu, 21 Mar 2024 13:23:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 3650E6B00A6 for ; Thu, 21 Mar 2024 13:23:01 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EAE2D1604E8 for ; Thu, 21 Mar 2024 17:23:00 +0000 (UTC) X-FDA: 81921716520.30.2E668B8 Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by imf23.hostedemail.com (Postfix) with ESMTP id 081BA14001B for ; Thu, 21 Mar 2024 17:22:58 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2+QB2k4C; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.219.175 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=1711041779; a=rsa-sha256; cv=none; b=BYQBKRHrCJqfmfKaxAN6j2ny+8JfKP8z5qkjmJB02+BGyU8JdE0pa2UgC2x470BrIrkbqX tly1IzzR4MzGNyeMJRHI7a6lFEgZpOF7QFzyup3eafkn+nYWSxvQ3v40zX7rSpfEuWVQSb ZeRDo5zYrS8uat752BuMYJGYpK8D42c= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2+QB2k4C; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.219.175 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=1711041779; 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=w4sCto2weX/tSraSWS0s5CjzL8cyi2xaSDvgaVtTzPM=; b=bZghT9xD1eAFmrxzLDV5QrkirxC+SeCUnT1ttsl6ny3nvbJIL5T+OXyeS7WCKSgLofmX4/ cFGZzkb20gyFqrPbNnYmjqdCGGyVmSycvzr4il/GtmvDreNeJuZyF7GFmFIYjSJqtCVRlz L4tcK1j8Lyh57OkdmuG2Hnh1FRHPwPs= Received: by mail-yb1-f175.google.com with SMTP id 3f1490d57ef6-dc236729a2bso1169342276.0 for ; Thu, 21 Mar 2024 10:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1711041778; x=1711646578; darn=kvack.org; 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=w4sCto2weX/tSraSWS0s5CjzL8cyi2xaSDvgaVtTzPM=; b=2+QB2k4CRU7Dpq2epeJ/193u165Wbz8YjrZ/42b1AbU69y2xBfNO8tEtk4QXueYDTw 3U399yekYfbyPvZpDe71/NjkLmCAj5tjzthPotz+ziYTp/FJ/rMjs9z1g4jwxnV/3ZKM HbSBYdYgcIDIWZQEdZpePpYOBnOuvF0d9t4l+kSj13CZOsrsK/JmnsnhUmYgu4Rk8p0c DsLIigE9VuiWlGD52bvgC9SQv5U1w+wN0s8MHqYFCDze3m/W4vZlGuLXIM2ULVqft9cC DI/wlbBXYYMvTbY7SiiMqGHg5dw8QbBMBW4s6opwZWDM53gs59pxnZ2RiC17Wopdy30b wtjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711041778; x=1711646578; 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=w4sCto2weX/tSraSWS0s5CjzL8cyi2xaSDvgaVtTzPM=; b=AOEGeJX79Qch98sCRzxCXlBaCtcKlepIn3jHev/3Tmggfsf7do196edJ1A5qwDAqDF K+cI5QgzN050aWSVHBUbQ/o5Exz2s7wZi4PVa+LXBnxrN6Rrw5WzjSO5lNC6I4/a9ILx c1nVaaGK9Cp5bqwwmeWLSAMTtNckkHzH+5BCK7KKRnrAZncU+0rrdQdE/Po2MRmLdRNn lKP+F9QPUzi/oGvOWQRLCLcUqQUeTjb2SVEaQlBXPabRV+QycNqU9sYhAwYI6egAFDQB B+wV04Kic3Q6EsszUCx5wQU+lbVjJvOi4EZB37g8peS2X80fUr1x7k4A9b92bfxrKtVA dAKA== X-Forwarded-Encrypted: i=1; AJvYcCW6M14hRp9dkpr/oqE+Vz4axTT4GIgHNAmnJti62E8ixeIwMasPjvRGhM1aCwcARoUtbwJQ524eUzQM6cwHVJsshMQ= X-Gm-Message-State: AOJu0Yy5GVW81LSc/sQjyMTPZfpNjRKNKi05+r5i/kOP6v9TUXQ408Nt cbEm/co9PfKuPQ6imVOy/vtpenSX3p1XW7o9zBllkNuOSUlMmBBHJTHxRYb4lB5FP/9Vuqcn62Q PZdkA9aMi8oB5THyl4NCDCZgs19Edb151najB X-Google-Smtp-Source: AGHT+IEchVac4khjBai8ZMUeOEG+pay6R0DITToEq3FetB5+Bz6Fx0tQ3dmiDUpIWg8REeoZLlH/6+Ca7JUBqPCCrBc= X-Received: by 2002:a25:3607:0:b0:dcc:323e:e1a4 with SMTP id d7-20020a253607000000b00dcc323ee1a4mr19870609yba.6.1711041777566; Thu, 21 Mar 2024 10:22:57 -0700 (PDT) MIME-Version: 1.0 References: <20240321163705.3067592-1-surenb@google.com> <20240321163705.3067592-21-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 21 Mar 2024 10:22:46 -0700 Message-ID: Subject: Re: [PATCH v6 20/37] mm: fix non-compound multi-order memory accounting in __free_pages To: Matthew Wilcox Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, roman.gushchin@linux.dev, mgorman@suse.de, dave@stgolabs.net, liam.howlett@oracle.com, penguin-kernel@i-love.sakura.ne.jp, corbet@lwn.net, void@manifault.com, peterz@infradead.org, juri.lelli@redhat.com, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, peterx@redhat.com, david@redhat.com, axboe@kernel.dk, mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, dennis@kernel.org, jhubbard@nvidia.com, tj@kernel.org, muchun.song@linux.dev, rppt@kernel.org, paulmck@kernel.org, pasha.tatashin@soleen.com, yosryahmed@google.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, andreyknvl@gmail.com, keescook@chromium.org, ndesaulniers@google.com, vvvvvv@google.com, gregkh@linuxfoundation.org, ebiggers@google.com, ytcoode@gmail.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, bristot@redhat.com, vschneid@redhat.com, cl@linux.com, penberg@kernel.org, iamjoonsoo.kim@lge.com, 42.hyeyoo@gmail.com, glider@google.com, elver@google.com, dvyukov@google.com, songmuchun@bytedance.com, jbaron@akamai.com, aliceryhl@google.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, kernel-team@android.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kasan-dev@googlegroups.com, cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 081BA14001B X-Stat-Signature: hcpwqtc39dp4bg58qy1byidhq7y9d5yf X-Rspam-User: X-HE-Tag: 1711041778-744427 X-HE-Meta: U2FsdGVkX1+BP5vnrTUWJu9BWW0/2tPcQqeqOPN4Q1K2Fu4sAwU0jl2b+zSUL336F5wzAvStCx+tmV74uOMuRhqxv6q7A5k9SGr+37M+eysfM+HQfO+fmzj5Zsgvmwopp0MJwaMJYOkL+YsuzKSVqFYX9AH01K+L/XslQomZ7EvrfoKaAsUGdZ876H31InjHI+8pYVr93v3jhcfiO5eRyJ95ycjnti3uZqgPV7xKBhz+HNdkqKA4uezLd+MER4G/NEW7q80eNaxo+KaGwaOxpMvQpCkS+5tshD88RDLiTugw9VeE0aP62zLpMSLIiyI95BLYpZi8ksPaG2gf85zbwT2ZpymhGpf+Zsy2ob4KiYNEnXdunskbvt+B8a6oDiG+9Re14Mol007Q054R7l9w/Q/IM+p+UvfTALsXYuL0k5xxBK/wyKmsU2CkAVghxVJNvZvCMw1znEaC2xzdAdgKzLxRKIoZepMMC882DUF1dBdiSJDGTIv+g4ayNlYEreM3E/CguStgijWeVZPjCLD/USqRun42gHslICaWBEz7tevbYPXe6kEpj8SJWP23wklXSSkoySNHZFUieC3Pm3+n+JRkeXQmPsyJEtpSZqnQPH4UNnBq5B0swvWGaQCqaeKRAu4Jzwls5TxOuiSNV8SCXxYb01lsP0xvXKDaodxd7uLGGeI3QNrZ5aWtHpwlM3xY4mp5gKUMTg/Pues9lav9RUMUPuBM9wtuw8YfXPJu4TXcRjtmGQPwrtfTPkBY29ZT3TlZiTNxylJoaXt2zpbbNpEIF685tMtUkruDXN744ygkYQVS5q+6oXd3TF3flk4QX9kJywtyyzhhXeUFfJBdxF1JuzA0FQ6TxCw5RidrzTdqmdyxV8Lf2xlt+LU5GeFM4M+b65MGpVaPt9IF0Q3yBtzE0VJze6Je4XW1JqX7nASsUFhBFyUp6zCSyFkyC95wZpvb052psrgaTawzLtg XIw7dM96 kdNs3BC2Boj657sYsGdQCQzwskXv10NWVf+7FRVrDmcSCy02J7JTGjgPS35lGK6dhdWjRRdTUEm16m+6eyd6igapSVoGmz85iznPMnN7+nHWNTXWxIvFgyCkwjMW2f73gayoR/8vz2n1HqvuywUvwXvMgKn3J9akKtOYDnjh2sm6skGOuyo8w2+SOvEWPbBeLXmO7QTBVec4mU/DGXTC07hTvcwPOO9mBHKEznK99BSUuDdVHxP4MQ3BO3NqOjwt7W+KRsxxWp0UaXwdgyD3GaQD4VP+9pCOuPEC/I5Mty7SwImcSxk8LWvFVxLAitfrBZ7vNS7JkBQIl8BDTFOCNWUZpSBtL5sKAsum0/7gvcHQ3WScxIKBysTNntc4XtwUG8xEalg0SgugewWz9CPJboUBXBd9AiKOE8gYJluw3DrSywYh3PjgefadMeIUeoVWgQffA7MfgZh9pHDo7QmcpyjCuGJJBG6wgMhAJImudoZOhZ3D2B2S1IvaVEwJL9wkjp7CQ 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: List-Subscribe: List-Unsubscribe: On Thu, Mar 21, 2024 at 10:19=E2=80=AFAM Suren Baghdasaryan wrote: > > On Thu, Mar 21, 2024 at 10:04=E2=80=AFAM Matthew Wilcox wrote: > > > > On Thu, Mar 21, 2024 at 04:48:53PM +0000, Matthew Wilcox wrote: > > > On Thu, Mar 21, 2024 at 09:36:42AM -0700, Suren Baghdasaryan wrote: > > > > +++ b/mm/page_alloc.c > > > > @@ -4700,12 +4700,15 @@ void __free_pages(struct page *page, unsign= ed int order) > > > > { > > > > /* get PageHead before we drop reference */ > > > > int head =3D PageHead(page); > > > > + struct alloc_tag *tag =3D pgalloc_tag_get(page); > > > > > > > > if (put_page_testzero(page)) > > > > free_the_page(page, order); > > > > - else if (!head) > > > > + else if (!head) { > > > > + pgalloc_tag_sub_pages(tag, (1 << order) - 1); > > > > while (order-- > 0) > > > > free_the_page(page + (1 << order), order); > > > > + } > > > > > > Why do you need these new functions instead of just: > > > > > > + else if (!head) { > > > + pgalloc_tag_sub(page, (1 << order) - 1); > > > while (order-- > 0) > > > free_the_page(page + (1 << order), order); > > > + } > > > > Actually, I'm not sure this is safe (I don't fully understand codetags, > > so it may be safe). What can happen is that the put_page() can come in > > before the pgalloc_tag_sub(), and then that page can be allocated again= . > > Will that cause confusion? I indirectly answered your question in the reason #2 but to be clear, we obtain codetag before we do put_page() here, therefore it's valid. If another page is allocated and it points to the same codetag, then it will operate on the same codetag per-cpu counters and that should not be a problem. > > So, there are two reasons I unfortunately can't reuse pgalloc_tag_sub(): > > 1. We need to subtract `bytes` counter from the codetag but not the > `calls` counter, otherwise the final accounting will be incorrect. > This is because we effectively allocated multiple pages with one call > but freeing them with separate calls here. pgalloc_tag_sub_pages() > subtracts bytes but keeps calls counter the same. I mentioned this in > here: https://lore.kernel.org/all/CAJuCfpEgh1OiYNE_uKG-BqW2x97sOL9+AaTX4J= ct3=3DWHzAv+kg@mail.gmail.com/ > 2. The codetag object itself is stable, it's created at build time. > The exception is when we unload modules and the codetag section gets > freed but during module unloading we check that all module codetags > are not referenced anymore and we prevent unloading this section if > any of them are still referenced (should not normally happen). That > said, the reference to the codetag (in this case from the page_ext) > might change from under us and we have to make sure it's valid. We > ensure that here by getting the codetag itself with pgalloc_tag_get() > *before* calling put_page_testzero(), which ensures its stability. > > >