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 77072C5478C for ; Wed, 28 Feb 2024 17:51:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C29E66B009B; Wed, 28 Feb 2024 12:51:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BDB676B00A2; Wed, 28 Feb 2024 12:51:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A7D956B00A4; Wed, 28 Feb 2024 12:51:06 -0500 (EST) 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 95C616B009B for ; Wed, 28 Feb 2024 12:51:06 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 170701A1080 for ; Wed, 28 Feb 2024 17:51:06 +0000 (UTC) X-FDA: 81841953732.22.A08A85A Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by imf19.hostedemail.com (Postfix) with ESMTP id 767D01A0021 for ; Wed, 28 Feb 2024 17:51:03 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zRw9fGaR; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of surenb@google.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709142663; 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=VnQ/ab/JPnAloJ9klQyh8nICmNuzmA4WCeR9lmsJM4M=; b=K/BRC8oAqqHMCkrz0t/3dcX/jaXaWR9UBp7mMbK2oGDerAC8SNbW28z+aO75BHvm3+1KlR GdKf3A4tA/voK6Xeu6oHs3Nog55eHKY1l11zUEzFaGZ5BqmMjgpWJN4taG+STk+bES0cZy wzQk5toTC+0PNNTa+fmOQWOLlWopK4o= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zRw9fGaR; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of surenb@google.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709142663; a=rsa-sha256; cv=none; b=tb7jcGI8L37jqWgn5/mLz441ZRpKEQ3xHWXfJz6rejU9mwvFWqa2Nx8d4mlWemIiHA4CC8 leHwdQlUsA1CeG3+M/OPiUVVQxT6SNxi5NpXz1vGsGZOLw0YPGdwHWk7R71crSJKlHaJ8V 14JCoXiwWjYyo5bVO+gUKlXrF/VpRUA= Received: by mail-yb1-f173.google.com with SMTP id 3f1490d57ef6-d9b9adaf291so54420276.1 for ; Wed, 28 Feb 2024 09:51:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1709142662; x=1709747462; 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=VnQ/ab/JPnAloJ9klQyh8nICmNuzmA4WCeR9lmsJM4M=; b=zRw9fGaRf4lfkTzEcC8WZ5V/EVCiUEaYgobqDd4ojg0MKlG4Kpg1GDLYw7eThGjVmI aWOa0AypfTG9BIoHygpsGWZJxQbp2U+GMqMhB/Gp50ELwEeOYGNJebmocr8qNudP9zVV KVR5DU7IDR0Zh8im691N/iIcbvs5KUSPYM2BnXbOhSKJIKnxmTDGjhOSbb2NWqV3YRPl S/e2rtBSijHSik3RK8n1l4WgvCJSb6jaBJklrRm8VDG22V7yQQAkwkP1VVWZm9jy/PhO tXwQ2QISyhnj7hdD1y/ljZJ6jSAZc3gwgZnKT2ZOSN0Ynhfr2Szq1st/dRiltQKOCNXR hmeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709142662; x=1709747462; 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=VnQ/ab/JPnAloJ9klQyh8nICmNuzmA4WCeR9lmsJM4M=; b=ib5edx2O+zd1q5I7WbXGO5mYGYTXTOsFR0vMj9O54xFn/MlUFka//PKgldw3z18g4A dn4xw9+nAqzO4G3Mm13NkkYzksIMHrdrdVaCSUIzUuAokQXrrnrWa0vvmK821L+9jR8b xo3LQqwwhu13rVJAreFbuCkQW7f1kHcFOv7TfV33woLReYbrgaBGtj3JJjyEBw1J8YBG /QLUMM5Lw8Z77y/R2vdH341Rc4lqz1EYLVa+LMTatoB3rGHNnp4iLp+LEhhaJg5Au9TH Q+a+czaO/dfMk5MQXtNx80zlUW3C1Nnwzr/RcD7oMxfUUdwUza0VhGb2MtyMumWi4fWs 1vgw== X-Forwarded-Encrypted: i=1; AJvYcCUoRqKHvtip8+GqXJzfj9dI7XlqcZJRgRjrB0500p/F1uK1Da2QNY5rhOtRhPfP13hVPADuymSy3u0c+5BwiVlkNmE= X-Gm-Message-State: AOJu0YyqUJ8lv9733M96XfejQZGPA4mmcj+P79+dH1ycpTXdtbjcBxFK I79jAY2QRf/rdksmdLziAT2hJy4CtUt/FpTHvTi2jBDi0YaxRxwXo7jFXTee4IooQWFCdhuwN+2 8oKg+Eg6WZ+914OpTmjmmFuyIKDNUiHpHp3Ib X-Google-Smtp-Source: AGHT+IG/EeCjxcbMnwV3xlMkTlCAxh5CrdaPO3GQcKcWzYKjyw1uLk52luOW0XOEQwoUYKADdxDUo6eSBLFJyH16/wI= X-Received: by 2002:a25:9c08:0:b0:dcb:bff0:72b with SMTP id c8-20020a259c08000000b00dcbbff0072bmr3550ybo.31.1709142661963; Wed, 28 Feb 2024 09:51:01 -0800 (PST) MIME-Version: 1.0 References: <20240221194052.927623-1-surenb@google.com> <20240221194052.927623-20-surenb@google.com> <2daf5f5a-401a-4ef7-8193-6dca4c064ea0@suse.cz> <6db0f0c8-81cb-4d04-9560-ba73d63db4b8@suse.cz> In-Reply-To: <6db0f0c8-81cb-4d04-9560-ba73d63db4b8@suse.cz> From: Suren Baghdasaryan Date: Wed, 28 Feb 2024 17:50:50 +0000 Message-ID: Subject: Re: [PATCH v4 19/36] mm: create new codetag references during page splitting To: Vlastimil Babka Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev, mhocko@suse.com, hannes@cmpxchg.org, roman.gushchin@linux.dev, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, 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, 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, shakeelb@google.com, songmuchun@bytedance.com, jbaron@akamai.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: rspam09 X-Rspamd-Queue-Id: 767D01A0021 X-Stat-Signature: 544u3jac3fwopomec7h4hoot8j7gxomx X-Rspam-User: X-HE-Tag: 1709142663-7569 X-HE-Meta: U2FsdGVkX18Dc2j6DdA6jlMJ+y+HXiitSQGNsdfExFEe/V+yp2Dtr8AUYc1zHtkTEC4PXHD5jFErIiFQt1cqkFQDLDpq4rlu/b3CeH9Zxve+N4dGSMu0cY8d/WTnbXYZAGjWzbwpi2shGtBNGuhhzBCXM+upnaVzF5k7kxSDamDZeGHlB0r/GzEGHaI/Kl7frQvpSRICMPkMWCAU6AF0zn50dT4dnVYBQlqvrGGhpGBla7cGFdfsLSHoKljQTBCPFXecuOl70CnNpI+4mrW/VoRwkf/eXaGu0c5V4QfCrFmd22Vaf6kc8tXrf7qQ8QWuuZiAAVHR/clwMFp809xGvefFlhI95ZTbCjOBwmPQ6HlpnW2FaiaXkGKwNpUDGjUFiIlhzFkF53wM/5nHoY+7L0IeGk6ZCBw/q62cfII3CgS8QLTxCDDtmEDfWLdmDu0AMF3LoMUO1SKar9YNyVIyVKjmEB9fnfsBYsmYAOgv25R+Q+iMhdD6Ivd51e7aa6sCam7625tx/eKYGEkq3zW9+93dKwTTcjpl+mGzQXrxp+5oQzZ8hvODsG3K6yqEeu+W+IQ8sM99p3W2laMVzjbkYnWw7l7wgLRtSZVHJLe5T8xvWdF7Avh7/aiQpMmETH7NFLkuqOEasnrAXp+hrhXaR2DMLe7iPSecW6b4GpW8o+Jh6Gmo6QH/5SauYxzQWiBlQVoATyk0upFLECYHJo5qHQaOTu0SjUACJRB6+b7+KvubZC3RFbDYWpII2CZsBY99n6p5a0YOwOi3UNw6VDTXFbbOkI3YsYOcW9DM5CNNMb5DDF/0Hmvfh6J62W8UnIBMmM5sOPsAywDMdX18+Sv3VV11JvHL3Aq3NgR1cbLDzQhifkv1fwdfdGJuMA+Y5im+dYUUxDxXM2ZK4TTeni+HW8lR8zw1PuH5vAn4CiCD4pBZ6m5ZUJGMXBO5qmE9KQKRvnLynb+PIiF0G8d6ZLO 9BOQN/Cn 4xXDnFzD2+jXZHDJidZ0Dep/a8guqzya0hwEDlT5KGVWb0IfaXs91BuniqUthkQDJv6g+ 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 Wed, Feb 28, 2024 at 12:47=E2=80=AFAM Vlastimil Babka w= rote: > > On 2/27/24 17:38, Suren Baghdasaryan wrote: > > On Tue, Feb 27, 2024 at 2:10=E2=80=AFAM Vlastimil Babka wrote: > >> > >> On 2/21/24 20:40, Suren Baghdasaryan wrote: > >> > When a high-order page is split into smaller ones, each newly split > >> > page should get its codetag. The original codetag is reused for thes= e > >> > pages but it's recorded as 0-byte allocation because original codeta= g > >> > already accounts for the original high-order allocated page. > >> > >> This was v3 but then you refactored (for the better) so the commit log > >> could reflect it? > > > > Yes, technically mechnism didn't change but I should word it better. > > Smth like this: > > > > When a high-order page is split into smaller ones, each newly split > > page should get its codetag. After the split each split page will be > > referencing the original codetag. The codetag's "bytes" counter > > remains the same because the amount of allocated memory has not > > changed, however the "calls" counter gets increased to keep the > > counter correct when these individual pages get freed. > > Great, thanks. > The concern with __free_pages() is not really related to splitting, so fo= r > this patch: > > Reviewed-by: Vlastimil Babka > > > > >> > >> > Signed-off-by: Suren Baghdasaryan > >> > >> I was going to R-b, but now I recalled the trickiness of > >> __free_pages() for non-compound pages if it loses the race to a > >> speculative reference. Will the codetag handling work fine there? > > > > I think so. Each non-compoud page has its individual reference to its > > codetag and will decrement it whenever the page is freed. IIUC the > > logic in __free_pages(), when it loses race to a speculative > > reference it will free all pages except for the first one and the > > The "tail" pages of this non-compound high-order page will AFAICS not hav= e > code tags assigned, so alloc_tag_sub() will be a no-op (or a warning with > _DEBUG). Yes, that is correct. > > > first one will be freed when the last put_page() happens. If prior to > > this all these pages were split from one page then all of them will > > have their own reference which points to the same codetag. > > Yeah I'm assuming there's no split before the freeing. This patch about > splitting just reminded me of that tricky freeing scenario. Ah, I see. I thought you were talking about a page that was previously spli= t. > > So IIUC the "else if (!head)" path of __free_pages() will do nothing abou= t > the "tail" pages wrt code tags as there are no code tags. > Then whoever took the speculative "head" page reference will put_page() a= nd > free it, which will end up in alloc_tag_sub(). This will decrement calls > properly, but bytes will become imbalanced, because that put_page() will > pass order-0 worth of bytes - the original order is lost. Yeah, that's true. put_page() will end up calling free_unref_page(&folio->page, 0) even if the original order was more than 0. > > Now this might be rare enough that it's not worth fixing if that would be > too complicated, just FYI. Yeah. We can fix this by subtracting the "bytes" counter of the "head" page for all free_the_page(page + (1 << order), order) calls we do inside __free_pages(). But we can't simply use pgalloc_tag_sub() because the "calls" counter will get over-decremented (we allocated all of these pages with one call). I'll need to introduce a new pgalloc_tag_sub_bytes() API and use it here. I feel it's too targeted of a solution but OTOH this is a special situation, so maybe it's acceptable. WDYT? > > > > Every time > > one of these pages are freed that codetag's "bytes" and "calls" > > counters will be decremented. I think accounting will work correctly > > irrespective of where these pages are freed, in __free_pages() or by > > put_page(). > > >