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 C198ECD4F32 for ; Wed, 4 Sep 2024 21:07:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 50F296B0106; Wed, 4 Sep 2024 17:07:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 496BD6B011D; Wed, 4 Sep 2024 17:07:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2C3656B011B; Wed, 4 Sep 2024 17:07:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 0ABA36B00DF for ; Wed, 4 Sep 2024 17:07:50 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B016B121497 for ; Wed, 4 Sep 2024 21:07:49 +0000 (UTC) X-FDA: 82528292658.28.D4B78A1 Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176]) by imf27.hostedemail.com (Postfix) with ESMTP id E039440003 for ; Wed, 4 Sep 2024 21:07:47 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=1D4o+8sm; spf=pass (imf27.hostedemail.com: domain of surenb@google.com designates 209.85.166.176 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=1725483991; 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=w42R7BNbzfV9m9Ak5XplqSqEhc1UT4kjpkgNMP3MoEY=; b=7r8lGNVT+VxLcBjwBEdXy/CV7xcKvPeXKB5X5EIUoKt2un8RLUAS1GRqzZTvRBfJAdylKR DXNLVctYWjpKuBknNgsfznW96pqCjn9kDJrkxbMTowkTL2vGWTIuis6BiAsv/57C60BJbl DckC/ehXfaOwYCbxmb22rbT4OGOX4vw= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=1D4o+8sm; spf=pass (imf27.hostedemail.com: domain of surenb@google.com designates 209.85.166.176 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=1725483991; a=rsa-sha256; cv=none; b=LUwWuEw2dtVfNIcaW8ykQlEGbVKytKm00doOwO2IPvvW12yS52QKgHzSGCphH/aT8E1jn1 jZrkRjdFrpEeyiI0XOpbEYBLquoLWDCLlcYcI1b6K9Zv/4YaTMrzG58mh8KmwhaGMK3XAQ FdMly3aJ5pQF7UicT87UHnF1/tKzKqc= Received: by mail-il1-f176.google.com with SMTP id e9e14a558f8ab-39d3ad05f8eso19495ab.1 for ; Wed, 04 Sep 2024 14:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1725484067; x=1726088867; 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=w42R7BNbzfV9m9Ak5XplqSqEhc1UT4kjpkgNMP3MoEY=; b=1D4o+8smlZ5EQSvOuYTak+Sgego7OeTkvOG5o7pTFxtuG0He/uZFMm/LKtjy9HgdhF l2wKVFjVBaJUt+IXRg/ln6zcYF96zWSsHYhY7IWJiEnPG/vyAMKXNcbPwjMvKIhCO5xi 2hz1ImTJ4dQbY6qexf1g8SsaxwcFgsSjs8AOcXIhuyLMEu0Q2oPdIs3DEURmH7hKbAtV XyNBrm3T91KXoTRMlbwVbkyekg2O873OiDYp5qaxr5pIoTkDnk6wajAopHSuYePW02cU 0dRWx3wzhh9Cc/4/9YO8DAp11d9eAdVuZZXPU0cYRzfGJpsE/RVswl8IWvA7EtPG7z90 RfwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725484067; x=1726088867; 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=w42R7BNbzfV9m9Ak5XplqSqEhc1UT4kjpkgNMP3MoEY=; b=VRHwB8bIvRbXV4QofLPwJmv78voARue6fImLHv/PmNtGQTB+VZzQexQeW5io6oE//O joFR/sPfxci4mbPZcs24m0DoztnMng90aiZgbChS0J76WZ/qSyBPPpCqu5ePqIqXDpps qVg+oYST3kxyGn6BsjXq7rPTKZbSim/2Hr6+/PlN5VAA0pa4ZaQrkjALKacLtgsiBgKt eqvBe1aMcBTRSlKs6D7P+kDNIfEpjHkb/U3YyvixN5mkjiQwazDalm78OQ5I6inhj95N tFp1U8cdk/Bhh+bAozO8r0Z+e5jlQb1vOWAQsyshHIF2vALiSzL9C7z7EPwbcmccVB4L s4JQ== X-Forwarded-Encrypted: i=1; AJvYcCU6yFMbvphq/aAUfWSLXCn/AuZJ0v4lRbBINX8dS7gOL7UHUGNE/Ab85uotJK1SCqS8Z56vHYgwrg==@kvack.org X-Gm-Message-State: AOJu0YzbLLIwCGywfg+qBafFYre5hRXlZle1gAhsJLetNBzpoTepYHbg L8TkzLizmA+ykACr552+zKvPAWI9IuNRHqMlhYwlq6mDU4UNwaGT+vYJFMAZBhKsMwQ5OFf0QzF s4aiH3doHXSPHlzvi+hPrHxTJI+6prTvDA+NR X-Google-Smtp-Source: AGHT+IGl61F4f0ftYFMGsiQbwYzHE/z5H02ZJShnK57l4cZ0n0C26unhLmoZ1lt/9kS0S1twnCdNwstxD7QTkD9leS4= X-Received: by 2002:a05:6e02:194e:b0:377:14ab:42ea with SMTP id e9e14a558f8ab-3a047199bb8mr996875ab.16.1725484066426; Wed, 04 Sep 2024 14:07:46 -0700 (PDT) MIME-Version: 1.0 References: <20240902044128.664075-1-surenb@google.com> <20240902044128.664075-7-surenb@google.com> <20240901221636.5b0af3694510482e9d9e67df@linux-foundation.org> <47c4ef47-3948-4e46-8ea5-6af747293b18@nvidia.com> <70ef75d9-a573-4989-9a9d-c8bc087f212b@nvidia.com> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 4 Sep 2024 14:07:31 -0700 Message-ID: Subject: Re: [PATCH v2 6/6] alloc_tag: config to store page allocation tag refs in page flags To: John Hubbard Cc: Andrew Morton , 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-Stat-Signature: mk1ttmbog7d59x5jcsmq7twe6qzj66w5 X-Rspam-User: X-Rspamd-Queue-Id: E039440003 X-Rspamd-Server: rspam02 X-HE-Tag: 1725484067-862705 X-HE-Meta: U2FsdGVkX19nRITik0eitnWnGu9qQTkO4wzxjelJfiv8usmeKIeq3BvxzXLZrmSm6YdVQ+y9U8WiuxZQbt/yL18IclqxeLNNQlOXaTP6tOHRYFCQbyiu9VbNwidWOnyc9vjAZ916od081+btcILYsoKjjw9l4V7J0wvd9EC3GdpXvJoYpVKmNQ3MN7K62mfXZEbJ/K2IGhbXOOUEOHaUOS3ytSxOIn3ar9lBZz8NezppSMqp38W5v2AIX5JyZsiCg+lHm2UP8+JQVsJhTdVcF0j1AYQkjGC7WRD6CZkG21i9BMuogwt3IGs5RWgqYMaDvOo+RX471HmJew2M7x8FdQRWsf8SRYUs66J1w5F7rAF0r2LTkc596fMaD02ismU4MuBhSc37b83oFTPRhugaJIgEkt76gYsqeMWiA8/cdgfd8ZdLb2E9eFLcD+Unpa5zIBQvtMLZS6mhACMM9zeWAOoKFNfaOnnbtRBx/YgoTWrW/O/21B4QxGGYFusFCcRibh1yAXTM/gpg3wtpC4hCrHgDIsGgCQcGcMXovOUI9a/AOWR/1zFn1FNtVL4SkEdaohfZgsOkMAPqIc45bfYHPQhqMMBbcKHB8zJU+V4oE5Yvi1RomPioSQzr6+WLHhmoGIBlfvj5f3gdU1ddUM+Od29VoD2+pHKKN+fBdnCWfaRZo0k2QQdVNJiKowG2e0H0Gl3rkvRiObg6ihoxASg1xz3f23WW6Ao4HX1rXLb5jvL4BCo5NuKUeZjvKB++05mcBVLBdl2O9QJJXhZAxYSJbyCuCXqwr1rDRL8sKFUOtzuroSyqFcygg8depIHGy1WRyuuLoka5JDBRxHEY4qWu7Yz0UprJXCdMG2xPmXbR994pI59FjSuuLiwIdGgM56C2TlVdIS2CKPrddgzk08fx06o/MbmaG+gm2JW8JNVdrLbWAFZnlbqHUR0jkxZT0nrFB1zV1svrLMC7u2my8HS XBnd2rD6 IMYOMPC69xT+T3Pbmp8LZ0/OdRKWIUjA0n2HuCMzziFlEh0ULaYrV1TqBbJzWhr9NSO+I2mWJ4lla36YfJxvtXbEKilOUy7LUspe03wy8fk9gnBvqpSHztf+2GLHFRIGWKyfupt6Fmy/dVBV8uUwuKVhM1xThnYeQrAE06WnhnGqe9nQYN/b9u1b0T9HfIGfvCIQxO0zFBAXzf/IlQMlqsXkL7ENuMAAuHB/RguGdCDmNf3uNv6rYjOXHBaBrJSu7TTkfoBSLxHbPWBkAycwVvKYLQ2lvcy2MUAGSIA93v1rHzCE21QZtLT4IWDcyD7tnoZRjtHbY+0DKc0p+kk3W+AXL7U9fxUCpmgdEPCBCwaTkqpUXtLNBiALIVw== 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, Sep 4, 2024 at 11:58=E2=80=AFAM 'John Hubbard' via kernel-team wrote: > > On 9/4/24 9:08 AM, Suren Baghdasaryan wrote: > > On Tue, Sep 3, 2024 at 7:06=E2=80=AFPM 'John Hubbard' via kernel-team > > wrote: > >> On 9/3/24 6:25 PM, John Hubbard wrote: > >>> On 9/3/24 11:19 AM, Suren Baghdasaryan wrote: > >>>> On Sun, Sep 1, 2024 at 10:16=E2=80=AFPM Andrew Morton wrote: > >>>>> On Sun, 1 Sep 2024 21:41:28 -0700 Suren Baghdasaryan wrote: > ... > >> The configuration should disable itself, in this case. But if that is > >> too big of a change for now, I suppose we could fall back to an error > >> message to the effect of, "please disable CONFIG_PGALLOC_TAG_USE_PAGEF= LAGS > >> because the kernel build system is still too primitive to do that for = you". :) > > > > I don't think we can detect this at build time. We need to know how > > many page allocations there are, which we find out only after we build > > the kernel image (from the section size that holds allocation tags). > > Therefore it would have to be a post-build check. So I think the best > > we can do is to generate the error like the one you suggested after we > > build the image. > > Dependency on CONFIG_PAGE_EXTENSION is yet another complexity because > > if we auto-disable CONFIG_PGALLOC_TAG_USE_PAGEFLAGS, we would have to > > also auto-enable CONFIG_PAGE_EXTENSION if it's not already enabled. > > > > I'll dig around some more to see if there is a better way. > >> > >>>> - If there are enough unused bits but we have to push last_cpupid ou= t > >>>> of page flags, we issue a warning and continue. The user can disable > >>>> CONFIG_PGALLOC_TAG_USE_PAGEFLAGS if last_cpupid has to stay in page > >>>> flags. > >> > >> Let's try to decide now, what that tradeoff should be. Just pick one b= ased > >> on what some of us perceive to be the expected usefulness and frequenc= y of > >> use between last_cpuid and these tag refs. > >> > >> If someone really needs to change the tradeoff for that one bit, then = that > >> someone is also likely able to hack up a change for it. > > > > Yeah, from all the feedback, I realize that by pursuing the maximum > > flexibility I made configuring this mechanism close to impossible. I > > think the first step towards simplifying this would be to identify > > usable configurations. From that POV, I can see 3 useful modes: > > > > 1. Page flags are not used. In this mode we will use direct pointer > > references and page extensions, like we do today. This mode is used > > when we don't have enough page flags. This can be a safe default which > > keeps things as they are today and should always work. > > Definitely my favorite so far. > > > 2. Page flags are used but not forced. This means we will try to use > > all free page flags bits (up to a reasonable limit of 16) without > > pushing out last_cpupid. > > This is a logical next step, agreed. > > > 3. Page flags are forced. This means we will try to use all free page > > flags bits after pushing last_cpupid out of page flags. This mode > > could be used if the user cares about memory profiling more than the > > performance overhead caused by last_cpupid. > > > > I'm not 100% sure (3) is needed, so I think we can skip it until > > someone asks for it. It should be easy to add that in the future. > > Right. > > > If we detect at build time that we don't have enough page flag bits to > > cover kernel allocations for modes (2) or (3), we issue an error > > prompting the user to reconfigure to mode (1). > > > > Ideally, I would like to have (2) as default mode and automatically > > fall back to (1) when it's impossible but as I mentioned before, I > > don't yet see a way to do that automatically. > > > > For loadable modules, I think my earlier suggestion should work fine. > > If a module causes us to run out of space for tags, we disable memory > > profiling at runtime and log a warning for the user stating that we > > disabled memory profiling and if the user needs it they should > > configure mode (1). I *think* I can even disable profiling only for > > that module and not globally but I need to try that first. > > > > I can start with modes (1) and (2) support which requires only > > CONFIG_PGALLOC_TAG_USE_PAGEFLAGS defaulted to N. Any user can try > > enabling this config and if that builds fine then keeping it for > > better performance and memory usage. Does that sound acceptable? > > Thanks, > > Suren. > > > > How badly do we need (2)? Because this is really expensive: > > a) It adds complexity to a complex,delicate core part of mm. > > b) It adds constraints, which prevent possible future features. > > It's not yet clear that (2) is valuable enough (compared to (1)) > to compensate, at least from what I've read. Unless I missed > something big. (1) is what we already have today. (2) would allow us to drop page_ext dependency, so there is considerable memory saving and performance improvement (no need to lookup the page extension on each tag reference). The benefits are described in the cover letter at: https://lore.kernel.org/all/20240902044128.664075-1-surenb@google.com/. > > > thanks, > -- > John Hubbard > > To unsubscribe from this group and stop receiving emails from it, send an= email to kernel-team+unsubscribe@android.com. >