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 8E31AD1D87B for ; Tue, 15 Oct 2024 15:59:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 104096B007B; Tue, 15 Oct 2024 11:59:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 08D546B0082; Tue, 15 Oct 2024 11:59:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E96FE6B0083; Tue, 15 Oct 2024 11:59:15 -0400 (EDT) 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 CA0E46B007B for ; Tue, 15 Oct 2024 11:59:15 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 976BA160664 for ; Tue, 15 Oct 2024 15:59:05 +0000 (UTC) X-FDA: 82676295576.13.2EA2C62 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf16.hostedemail.com (Postfix) with ESMTP id 5419518000C for ; Tue, 15 Oct 2024 15:59:06 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=IwPC69GM; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729007906; a=rsa-sha256; cv=none; b=XXxU8guRW/Hdn/Ul30awGQag44x0Zbe+PSzqoSNMQleUOvWhzgIesr+UI+cwI9SPTMDe4N wEMz5z949kgs9+tyfOtYTHDBpwZndSBlzGu20UERLVdhV3xYSy5+YjbGsFKJz0wB+0hePa WeELm/pR9z7hkb2flTBmr2LPFYsfSuQ= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=IwPC69GM; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.160.176 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=1729007906; 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=XE41Ka7vKxZjagEXLHac+Fwc56DYu0ANyHcZAa6jXdw=; b=aS+w0056O8DPKMUWHjGhIkjHHwiDnIpWbxKH12bJZAR6OCuGzoAg5fmSmudOmUOZ1ZdI2L hFSvtu0AjAywNeeOKLwHSOYnLfkIos0pLKVVLNX1nPnnkqGn3UHTaHqbybbS2NRBjbpcr4 kbgglq934/OMT//xg1oWwe4ZDmmWZoM= Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-45fb0ebb1d0so723071cf.1 for ; Tue, 15 Oct 2024 08:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1729007953; x=1729612753; 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=XE41Ka7vKxZjagEXLHac+Fwc56DYu0ANyHcZAa6jXdw=; b=IwPC69GMwJLX/cNMDTr5/2byBGrS/9eHDPr6qCFPl3vbAjJN7i4YR18amA7O2jOcic V17jP4dCfAKW+0NXCmVqoE+1E5uUZQJY28fvOuSmkQ/gX/NoRsEzFWQDftomyDNYgIWC lM9KSrWVGJ6+h/nbwrF6g9SBmG8r7rZf2KjK/ElbKTnOhbwllo0NsV+VfD2f/tYkyCTw ps3XZ0KdVmfhhDGO+pvJykN6JcA8/SHlb+RseHIw+dZx+TRlfzp77FbZrGDXI6rx9avI XskgtrsIX10KiJXZSEBXJ+IXIHTNgakp4Ja37WK2ER6/pjTNBWBnIcFrgXB56K6fm40e WAdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729007953; x=1729612753; 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=XE41Ka7vKxZjagEXLHac+Fwc56DYu0ANyHcZAa6jXdw=; b=D4RHbbkZLVhoDhGTOmYGyt8LW8ShxHrshVhm0mK9Dob1l55Dc3Bd0EWMlerAJDphpj +0isRd+lcxGOr8GHw7QTPtYw9Dxmc8VRYUTzYuNW0jMcXkpRiYmXvXFvLJTv24iRIc09 hmfNLt8f89lXtEmh539vt8+TrqR6m0M2gD1c7PSvWkcl8Y84f8G2rNIshTqeYvFclgtX M7U4KKn4S7gYbszd4QisdytKD/Ri4A1Ya5jM3PGSNMVs92AyGx7mJSNC4wo+8g4c0wyq 7uWaVbXBz0ZS8Igjqbex47G4mQg4AN9iTDpM9JQU7VnSmzWNh+cyBeSrpYWlrQHU5o/O zZZw== X-Forwarded-Encrypted: i=1; AJvYcCXkI4alKJp6X8r4F9ZvJdlPGs4zx70NK2WV9XxQH7XlA71HkmyYbYcSqIoYmpbkoWXKtMdP9siT8w==@kvack.org X-Gm-Message-State: AOJu0YzVmOdB+MyAaUy8N0PVhr3MzYJIo7DUClg/hNNLFJXassfwiVam N7KKZglx7B5HxNZzDOi8wyoLGKUuAxnYEyLwA7mQmyCDtB2sOOJLUdyPDACD5ARIOsP601HsE5z 2kpmqHEWIwH8dkATTLFMWOltCg91uiZMpy21A X-Google-Smtp-Source: AGHT+IF6xgKzdwApAz/tp26tbpQrjDXqxixmCCmxzkzM5PRyG4nrJ8/4jSASshjSbXG9ZNd4t2I6D2nt4kc3vxb6XWk= X-Received: by 2002:a05:622a:4b05:b0:453:56e7:c62b with SMTP id d75a77b69052e-46058ec036amr9300601cf.12.1729007952467; Tue, 15 Oct 2024 08:59:12 -0700 (PDT) MIME-Version: 1.0 References: <20241014203646.1952505-1-surenb@google.com> <20241014203646.1952505-6-surenb@google.com> <6a2a84f5-8474-432f-b97e-18552a9d993c@redhat.com> <9c81a8bb-18e5-4851-9925-769bf8535e46@redhat.com> In-Reply-To: <9c81a8bb-18e5-4851-9925-769bf8535e46@redhat.com> From: Suren Baghdasaryan Date: Tue, 15 Oct 2024 08:58:59 -0700 Message-ID: Subject: Re: [PATCH v3 5/5] alloc_tag: config to store page allocation tag refs in page flags To: David Hildenbrand Cc: John Hubbard , Yosry Ahmed , 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, 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-Rspam-User: X-Rspamd-Queue-Id: 5419518000C X-Rspamd-Server: rspam01 X-Stat-Signature: trmsbx4w6wr3epi3tgarb6uxqpgiydpd X-HE-Tag: 1729007946-345316 X-HE-Meta: U2FsdGVkX18cW4BebGDLQSS0H10449U2v9LNIF/diuLKiJ6mi+xWfkTkvXDL918UFifIK+W6ri4vzraLE9G4Em+TXpXlMYvMDaBtF802RF70mdeB7zcP3vG9IrHF8ThOmM0hovpKfJQ7wJEuyRU4lzGwwVw/m34SxzwRQz4UrkK+TEpsDMBkXOhLvoM9hkNab3Qev3r8npcDjpa+Zob1uUSbfTchlnmDisMaDqdhQf8A11ij12P5+MwKTZPr3TBFMKfG9nhJKtDfsCDEI+FPfhO4eu/sDtev+2zCdFe8VdmBO0QXcx+l9CPdlaLPvn7VF0PATLKEj3bHNOTx9KRYSC/jtMY1Vws8MWR/XguDX6lJpm/6CquzJQFF+RwAa7bxwGzdUG0PFxdwoFQDM8mYqGU7LWEYAy2cZqGDK2TO0etFQT8k4K4fhfPDsFJns6rx3zcPLR4lMuqrGJ/wVQV2KRYhqeKx4DLD5w1EXS4c+tKab/F0U789EYps+whTcIjUn94yfHqIMUbHs83UjgLk2btAWZAQbkYmlH321cVLPIHw0hcitVwvB3FozjICyeAM060ZUChrKeXSpO7zvM6jVyD64lMu2Q9vHWyFU7FD5KPI52PDvV3RNWZM3rsUyZR4P+qP6aEcLYQvZJJG5d7tOkc6g8XKJCsIFHVjDlytPkBaz6hb7S4TR6L7L/HrzuZxiYF/Bfg9WoWakrGJ89DxxKcjyLYE1GbsxqXGIaqueyCm1yZggWQVXqp7p4SzSyebZNj4HNl1sYuZNjPmXeTAB3x9G+Pnvw3icEeF4BKP0kKlzAQHx605OWmvdKtmyJ5h2gig8eCWFvHnuTPRo2JximiTMpjPL3Ccb3gHkpHp9HXv6FBgs9o/7hN9TZqbpmJlxE9sbRCj5WpdGFWMkZr88v6AciSL1mIEQQ0FKT5QjSt4zaEn2zn8V3gMC9E4HchIDz69NKQlL2gyHZ9sWrY +UhQuQsK YMPdL8g2pytC2jRTi0Biff0xSNIWLTmx56lbz+ZzriORzF9ml8HKrDsuhjg+c3LJeoc3H0XPH1o1NwK70dltznetAuStmcj28VdTpzdqLVaRBsXPX4Xw9pKlEraNLbmup4urYgj4sUwdF/hY8sMtiqDa4S3SIZ4zDnxhQXhcRbsWzpzlk9fr6G3kh0zxBVA1rBPELZf6zNPxRh9uCHxe1mew9CovECWErifNxVYXiqRLBNqUDwXaMNeE+eNqvYqi+YTAHezTUOauxBgU68U+4o7OGTRdRhBwj5Fr7 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 8:42=E2=80=AFAM David Hildenbrand wrote: > > On 15.10.24 16:59, Suren Baghdasaryan wrote: > > On Tue, Oct 15, 2024 at 12:32=E2=80=AFAM David Hildenbrand wrote: > >> > >> On 15.10.24 01:53, 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 bi= ts > >>>> in page flags, why not use them automatically or fallback to page_ex= t > >>>> 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. > >> > >> My 2 cents: there is nothing wrong about consuming unused page flags i= n > >> a configuration. No need to let them stay unused in a configuration :) > >> > >> The real issue starts once another feature wants to make use of some o= f > >> them ... in such configuration there would be less available for > >> allocation tags and the performance of allocations tags might > >> consequently get worse again. > > > > Thanks for the input and indeed this is the case. If this happens, we > > will get a warning telling us that page flags could not be used and > > page_ext will be used instead. I think that's the best I can do given > > that page flag bits is a limited resource. > > Right, I think what John is concerned about (and me as well) is that > once a new feature really needs a page flag, there will be objection > like "no you can't, we need them for allocation tags otherwise that > feature will be degraded". I do understand your concern but IMHO the possibility of degrading a feature should not be a reason to always operate at degraded capacity (which is what we have today). If one is really concerned about possible future regression they can set CONFIG_PGALLOC_TAG_USE_PAGEFLAGS=3Dn and keep what we have today. That's why I'm strongly advocating that we do need CONFIG_PGALLOC_TAG_USE_PAGEFLAGS so that the user has control over how this scarce resource is used. > > So a "The Lord has given, and the Lord has taken away!" mentality might > be required when consuming that many scarce resources, meaning, as long > as they are actually unused, use them, but it should not block other > features that really need them. I agree and I think that's what I implemented here. If there are enough page flag bits we use them, otherwise we automatically fall back to page_ext. > > Does that make sense? Absolutely and thank you all for the feedback. > > -- > Cheers, > > David / dhildenb >