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 95E28CFC505 for ; Tue, 15 Oct 2024 01:40:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2532D6B00A9; Mon, 14 Oct 2024 21:40:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 200FD6B00AA; Mon, 14 Oct 2024 21:40:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A1AA6B00AB; Mon, 14 Oct 2024 21:40:50 -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 DF8436B00A9 for ; Mon, 14 Oct 2024 21:40:49 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 698FA80720 for ; Tue, 15 Oct 2024 01:40:42 +0000 (UTC) X-FDA: 82674132534.28.FA1FD9B Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf07.hostedemail.com (Postfix) with ESMTP id 7F8994000B for ; Tue, 15 Oct 2024 01:40:37 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=SeEYUOzS; dmarc=none; spf=none (imf07.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728956416; a=rsa-sha256; cv=none; b=T+7JcSFSbdT4fCWiFhO4bSoD3oSieKRMXmGdq+yzuHuiJOa8ZBInUHRtf3GcLl94P8u85X sb7Y2DCLzesKs1za3TNETpKSl39wMYeJCLvlcLsDGrvn/SweNzdAsEX2DJrdwUPA0jcN2M wcoascHO/o7iygfLTa9A5BJ8UuJMJmY= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=SeEYUOzS; dmarc=none; spf=none (imf07.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728956416; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=gL9eg7AaSPXqzlXNIhBfZZxk+kS0I3YiOjFS+/uT7A8=; b=eVQcuRc0LifPNPNkJrKD+4MxeXyI3ZR9eGy4Vp9fRJGTQ9WqzuSdx4rgpZUrND96yar/PB EBwaktGVzTobQAQOgE6TZxhQtg7v7N8zTEjiSS/g2S6Ca09bfPlJwMdzJi3AQrju2ytyNJ fTS1riqe8tpzCpVlccdvxy2iJ72Kh2o= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=gL9eg7AaSPXqzlXNIhBfZZxk+kS0I3YiOjFS+/uT7A8=; b=SeEYUOzSZyOqn7LIjB4X9+wHY5 YIzZrSCOQkjE+WyPlKKBnGsEZvyVSoAkqYO6CHYoJp6rJI7ild63hVYGcQjvH2EeUEckgfuKHj6bQ EA8LnAU1v6aT56qTf+iIJhuVEve5OodtWcYWMrvSRRh38aJH811muk7lakYjsir1UjQJayTVmFE0f 8ja8caoySLSqXyGTK2uoW5LwwIyM8PaJubNm3SE4NQH2gLYIpbDP+PJbedEZMQbCdssa7OF95EpBw NEcRO7I1CijWlAzjBzQVqXMHYw8VbE1KH5bpXaOWMtP2/ZLBDckOgKxFA9yBRLAw5/D3b3iJ7um06 rdWHUA0g==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1t0WXn-00000003Oqq-1E82; Tue, 15 Oct 2024 01:40:15 +0000 Date: Tue, 15 Oct 2024 02:40:15 +0100 From: Matthew Wilcox To: John Hubbard Cc: Yosry Ahmed , Suren Baghdasaryan , 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, 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 Subject: Re: [PATCH v3 5/5] alloc_tag: config to store page allocation tag refs in page flags Message-ID: References: <20241014203646.1952505-1-surenb@google.com> <20241014203646.1952505-6-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: jqzehm9uozxbcmnntpxn696hhnsmk9t3 X-Rspamd-Queue-Id: 7F8994000B X-Rspamd-Server: rspam02 X-HE-Tag: 1728956437-789455 X-HE-Meta: U2FsdGVkX18Y5wIc4Yp5Z/oF/6e4m9uF3yVO3W3iQHwNW0fzq9Z4KcDmifNs4McnaSEGE0NKKy7WR0Hw+l9XTlnaLkchcAPdFar/YvvuvAfU2zzKtua+C59PzMHcwBZDcVi5p8fFY7ZxnW9OofWpmbWlubNTwNH2la8YrisB0ieQCZeav6mmSng7FUnGf/GV+1jPH0F+TdsuSfeSuM7SBchbbXIC5aBT2fnSU0WD1EmbR6xLjgedsnKFqyQq0j1e5nSmrWs6tswv8Kcd03AO+PpV3a62CxT5PHSu2gCSYmTLr3BRcmSugcPLDhbewbw22FEVo0iq74eEttvsqXNmBKBtkfHx/UHlLtj4RPw+vshWPa+HpT0hFzprrfB8KIfOd5F5OV7iLt0MIk+GCQrlI4aTRdxDofLWKEeUXZrvH/qrQqbmnt4/YHgQYmrQJhDMT/yglRuDnOWAzu5HnJIIS+kGP3QU3x4bCXesJzFjnqK+GE2VohYuq3p/+W1Rm0IZL2C5ly9XbCsSwK77kZM9yqCQDPPdC/0185hGkuyOaeZFoA2M47oyyUgLkS/hwJojnFNDj3y6z8QXzWswrGPIAinGgvGT7PhRdNMYr8zCIwinAJ75WPeDeFM3dquvpBCweIpbA6fCFeEW2oUUpm+KtVlNxAFcm0qeWZaSPWgbrApGM4qX4XYkqT4PirTol3qaiNt26PbJ35+2LCaX/DkTi9HpNnG22of+YOWgrsssb31AOXZY5s6hE4LjLQ+lR0YWNjUHNMDBlo/tU80sGsHcb0VtbsGBye4Qph1X3i5etPq1zjwunvAh1jWyoUBD3Do6kH6AzzlRRCVZz0E4HFARLVLUg671QgmTTyNaCxlt7nu1d8LleaC7Mk4O7eNkun4WO2Rh8U4nPifp9PP6coHaTSFxGWl2nVLH4GphMCVL4quCRVEGUfUTndbWvM9jvttIwtT1GWgYyy8Cw1VIcFW mH4JCN26 ojga29SbqrHiFqTUIBDZeMUzmt4gbRc/wQ2G9Jv6OGGdzTcveptix2o6jB5BLX0qHpF/DvcENwq0WHC12xYzsTuusAcH+rgyGlBfvTtBLMNc2Xw9OlqAPiCjef3sbwbTItyCn/5kyxhQv6P+xdU7dONBoqbYHPpuVjmwPiB4y+09JchnSmwHv+izZTxxrzg8zZJ8UhhxtAIVaKHMvehYApc3aFRa1e7F2UWbs/Z8IZE6B8voGDG7ByddNtI9nT6zT0i9oBFIWRyXA80WkhA+gjKHMYA== 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 Mon, Oct 14, 2024 at 05:03:32PM -0700, John Hubbard wrote: > > > 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 that > > the purpose of this series is to give the option to avoid using > > page_ext if there are enough unused page flags anyway, which reduces > > 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. Maybe the right idea is to use all the bits which are unused in this configuration for the first N callsites, then use page_ext for all the ones larger than N. It doesn't save any memory, but it does have the performance improvement.