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 839F1CFC277 for ; Tue, 15 Oct 2024 15:06:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A83B6B0082; Tue, 15 Oct 2024 11:06:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 12FBA6B008C; Tue, 15 Oct 2024 11:06:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F3A646B0092; Tue, 15 Oct 2024 11:06:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D84E96B0082 for ; Tue, 15 Oct 2024 11:06:50 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 0C18AC03F3 for ; Tue, 15 Oct 2024 15:06:41 +0000 (UTC) X-FDA: 82676163612.05.01D5969 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf09.hostedemail.com (Postfix) with ESMTP id 36C5114002C for ; Tue, 15 Oct 2024 15:06:42 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=QNGRHGbM; spf=pass (imf09.hostedemail.com: domain of surenb@google.com designates 209.85.160.170 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=1729004736; 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=ZQl9UHMbS2zpthn3YlCftCta2N9I8PKzHq+fgsLN3WU=; b=waxVUKAQDDxuqY4g5mRDJCeppUXALCnGlidelV8Kt6uMz5EBNerFb9I3hxp4U1QICP1Csf fCPx7iAmLs5Kf11v3PSPh0i/h4QbPXj8tv3P32iNaUClhFPjXNrstB43J59I1ZK62NbIAV 66T1DcOT4Rt+euKuWzvWA3xpk/quduE= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=QNGRHGbM; spf=pass (imf09.hostedemail.com: domain of surenb@google.com designates 209.85.160.170 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=1729004736; a=rsa-sha256; cv=none; b=WT2fRVm7LQRly6B/HMaY3CFdW+AiTc5jMXaUVsYc/p7hrt+3hr3KtTy1ps3ikSOVjfbrZ9 j6YTDEK/DVFE4aYt/kz+RyXJjka9+LYF5lpNTS/t3OdRHiyp8f3MVPmliyXPphLM+s41UH 0d9TvLn1lmwrM2eiMxGamB8dELxHiQU= Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-45fb0ebb1d0so704921cf.1 for ; Tue, 15 Oct 2024 08:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1729004808; x=1729609608; 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=ZQl9UHMbS2zpthn3YlCftCta2N9I8PKzHq+fgsLN3WU=; b=QNGRHGbMqxvWz+ev8qqnlNX0L/1aOE3Vs2SEKWAfG6I4r2Da3OPAwd5NZ1Squxvxq+ zGdTOP6NZHY/TNKSHvenreaK4HiE5ecKu6Vujtx0iHQb0YWX18CdZNa4+VPaLnad7CQn 3WlpPqmxqNcAX+v7A3UgBHxke4/jaVYik8tVHzzJK3pAMm9+WYblBtR7yBU8gxOesUYy NzgVXoZlnmSUe6BkAOSkRE7EdkJOYXQGRcV8K2dmu+MigNAHNOHMKAr+0c8YWv9ykOPs ufI50SezghIFddAcj51Ftn62AjJYxjf9xBViJwSzjDV/57FA2kBMlN4quDcyGOoQM2Xx RKeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729004808; x=1729609608; 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=ZQl9UHMbS2zpthn3YlCftCta2N9I8PKzHq+fgsLN3WU=; b=fTjkwHrMWNIdwEPGXyFK1V9bRAA78f7AEwt5a9/EXBiQPDGSeTC9c5Mu4KiVTpR6n4 lKt5u6qWUb8aXGe12mzp7/YJ+NTahaYqTeRp8QQ6+OulGDAAj89UyMg1REQVaRae21cS DCtZzKQ3RhLlmGS4t2hL1iTwW4tNPsDqhZA/SdkRbTdN88R7w4T3f8QkOK6bQmwhlI/K mBda0XZeCF4Rs/NvLH9jfbNgd64sbTLFOfmk36sF+AIU34a4EPxX1jAbLq1zaolj+5kd ord/IRvxsobB1Qn80zIJxJE8Semu/Lc2PBwwyfPYKQgDhOPzog8DShy+i6L7x+MgHoAz 1hsA== X-Forwarded-Encrypted: i=1; AJvYcCVKkpYuWhj/9DkCIZb+R8qjdf2sk3eeg6LQHTHtYE6lq/zLCVwACeQgaEQGQlGL2AhBQvj+vak7yQ==@kvack.org X-Gm-Message-State: AOJu0Yyeb/F3fVbhyC3vPSHsVO0MjhVu3C+EunPyZpflUK7MPIvqIR2A PDiXu3ZY7O4wUGeTgq0aI+AoQd8TkJh2Xlv78KvLznwyA8hYqWAslHN58utuXAgH9N+GI5Fm/3X q9uqEO+w487Ph4LOsx8cnPgUr5gJe3t9ygiKA X-Google-Smtp-Source: AGHT+IFz49w7sJh5aAv5suX/gv44ZHvixIsfk7pLi4CHMT74qdTtREKObwESHWojwr9bWtWWKSGe9xN21xl8GKoggmw= X-Received: by 2002:ac8:648d:0:b0:460:8406:2c2c with SMTP id d75a77b69052e-46084062ef6mr1391331cf.25.1729004807352; Tue, 15 Oct 2024 08:06:47 -0700 (PDT) MIME-Version: 1.0 References: <20241014203646.1952505-1-surenb@google.com> <20241014203646.1952505-6-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 15 Oct 2024 08:06:36 -0700 Message-ID: Subject: Re: [PATCH v3 5/5] alloc_tag: config to store page allocation tag refs in page flags To: Yosry Ahmed Cc: John Hubbard , akpm@linux-foundation.org, kent.overstreet@linux.dev, corbet@lwn.net, arnd@arndb.de, mcgrof@kernel.org, rppt@kernel.org, paulmck@kernel.org, thuth@redhat.com, tglx@linutronix.de, bp@alien8.de, xiongwei.song@windriver.com, ardb@kernel.org, david@redhat.com, vbabka@suse.cz, mhocko@suse.com, hannes@cmpxchg.org, roman.gushchin@linux.dev, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, pasha.tatashin@soleen.com, souravpanda@google.com, keescook@chromium.org, dennis@kernel.org, yuzhao@google.com, vvvvvv@google.com, rostedt@goodmis.org, iamjoonsoo.kim@lge.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 36C5114002C X-Stat-Signature: q5ftu1yrzzgsm1aj1d9ggw4f9xnecmmo X-HE-Tag: 1729004802-568534 X-HE-Meta: U2FsdGVkX1+Y5xoeMUonh+LbBvT2zlpclm3N52FieBKfs30dL86+h4vpw4YGEwYAfUC0fBDNVQTdnwyMPPlEVpve2gz02yewq9dYTSUAS34N/9mdnS281FR7u/Xvdz8grCojNoyvi+YJppMYmV3zRpglkb4T2zcdhIMViW1puEVWhRV6jA1ruSIwZjCHsz4YxTEcedb64U1Db7a+1s19mRWHqXmtjObflATc3jXFHXoI4HpSyqhvWwhSWAiGZWHccCHHAokYY584XI38hZvMFS8zwWJAanbEz0WZbJcpf6hs8+su6zkwF6zrKfMG56FSa+fgXDq1Q3LD4iDihKcODj5+AeDV917X3N5Y4HaSIwCC0A1r33WmcF3DxiF2pzJOTM2AvjpUGlDVDucWVo8X/nO+Fzjsi2fMAvgnAdZvOfR/TyiVPz/xHwdCorcNSxVV6WzAlGCWUE4D2yodCnhKx8VnHVoEEtxPEzVqDJI9/kP+Nae8D//JPXeQvQSvvvMq+NzWGewT+IqEH+veRyqO5c/NJtMZq/ZWKd4IwWk92P4XH7nMOfuc2jPQ7tX6QDeuhhs9fC2GdFtrj1qMz/rD0vgANnwweMGvw9vwe5XQ21LwF+HbD0tiL/SNLY1N4x0E2Egf5vU8E6uYlovaizuXst+JUw5QlGiwE8+/nT1pBUFZ8FTqJZaeXKuC3Za7UlnlgEyaKdQg1JOtgR4eXYxrdQ9X6i56DG7n6ET1dUoBEtOHGaphFxlSTG00LEgE5isDuxeZ1kM+jmecf4eKrFRdkIZ0zpb+N4hrGRBl2J2QuiKf7AU1O6GpauKIcCFGHp03vsci/GU7h/JwdNuA7gX9h7DtEj6ewUlaLh/qU/AVYJVBP5SuWMgkmp/Zz9xv2dATiFig79uNaX1kSoa8dg7AAn0NjVXwgURoMLw5sNOzPDu0X5NewshAcLqPtboARTq9jp1t6pKyi4Y9v8eYG5F o9rVMBv6 CDtMUUVOSBODWMjd1/Dig3cRVZvK1WYkWawKrvhu3YHNJWDi7STAtRA0OH5M+Hb6nvSYq2BagqTm2haXkbSN2bZ9csecjUfa4atafwZFvYw/4QqQVJ4xdJWyAg0ql8gYV0as/4IEEiGusogWgD/TDHckTO6Kqs2FTV6mDZWtMxWCzqXy4DVaCz8NK8fEhT6xHFq5q6KyY9f8zNPgjXZZwJmWAPq7W3nvqZkBzvMBy/pyzLyX32edA0LxnyB0v5bzwsmhbH47bOBZLkXSDeg/huehmNfcTWgqCVuU60ibel69R+loOzC7HAr3pfQ== 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 Tue, Oct 15, 2024 at 1:10=E2=80=AFAM Yosry Ahmed = wrote: > > On Mon, Oct 14, 2024 at 6:58=E2=80=AFPM Suren Baghdasaryan wrote: > > > > On Mon, Oct 14, 2024 at 5:03=E2=80=AFPM 'John Hubbard' via kernel-team > > wrote: > > > > > > On 10/14/24 4:56 PM, Yosry Ahmed wrote: > > > > On Mon, Oct 14, 2024 at 4:53=E2=80=AFPM John Hubbard wrote: > > > >> > > > >> On 10/14/24 4:48 PM, Yosry Ahmed wrote: > > > >>> On Mon, Oct 14, 2024 at 1:37=E2=80=AFPM Suren Baghdasaryan wrote: > > > >>>> > > > >>>> Add CONFIG_PGALLOC_TAG_USE_PAGEFLAGS to store allocation tag > > > >>>> references directly in the page flags. This eliminates memory > > > >>>> overhead caused by page_ext and results in better performance > > > >>>> for page allocations. > > > >>>> If the number of available page flag bits is insufficient to > > > >>>> address all kernel allocations, profiling falls back to using > > > >>>> page extensions with an appropriate warning to disable this > > > >>>> config. > > > >>>> If dynamically loaded modules add enough tags that they can't > > > >>>> be addressed anymore with available page flag bits, memory > > > >>>> profiling gets disabled and a warning is issued. > > > >>> > > > >>> Just curious, why do we need a config option? If there are enough= bits > > > >>> in page flags, why not use them automatically or fallback to page= _ext > > > >>> otherwise? > > > >> > > > >> Or better yet, *always* fall back to page_ext, thus leaving the > > > >> scarce and valuable page flags available for other features? > > > >> > > > >> Sorry Suren, to keep coming back to this suggestion, I know > > > >> I'm driving you crazy here! But I just keep thinking it through > > > >> and failing to see why this feature deserves to consume so > > > >> many page flags. > > > > > > > > I think we already always use page_ext today. My understanding is t= hat > > > > the purpose of this series is to give the option to avoid using > > > > page_ext if there are enough unused page flags anyway, which reduce= s > > > > memory waste and improves performance. > > > > > > > > My question is just why not have that be the default behavior with = a > > > > config option, use page flags if there are enough unused bits, > > > > otherwise use page_ext. > > > > > > I agree that if you're going to implement this feature at all, then > > > keying off of CONFIG_MEM_ALLOC_PROFILING seems sufficient, and no > > > need to add CONFIG_PGALLOC_TAG_USE_PAGEFLAGS on top of that. > > > > Yosry's original guess was correct. If not for loadable modules we > > could get away with having no CONFIG_PGALLOC_TAG_USE_PAGEFLAGS. We > > could try to fit codetag references into page flags and if they do not > > fit we could fall back to page_ext. That works fine when we have a > > predetermined number of tags. But loadable modules make this number > > variable at runtime and there is a possibility we run out of page flag > > bits at runtime. In that case, the current patchset disables memory > > profiling and issues a warning that the user should disable > > CONFIG_PGALLOC_TAG_USE_PAGEFLAGS to avoid this situation. I expect > > this to be a rare case but it can happen and we have to provide a way > > for a user to avoid running out of bits, which is where > > CONFIG_PGALLOC_TAG_USE_PAGEFLAGS would be used. > > If this is in fact a rare case, I think it may make more sense for the > config to be on by default, and the config description would clearly > state that it is intended to be turned off only if the loadable > modules warning fires. Just to be clear, I think running out of pageflag bits at runtime (as a result of module loading) will be a rare case. That's because the core kernel has many more allocations than a typical module. Not having enough bits for the core kernel might be the most prevalent case, at least for large systems. That said, your suggestion makes sense. Since we have to keep CONFIG_PAGE_EXTENSION dependency (for the cases when we have to fall back to page_ext), there is no advantage of keeping CONFIG_PGALLOC_TAG_USE_PAGEFLAGS disabled. I'll change the default in the next version. Thanks for the suggestion!