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 5351ACFC274 for ; Tue, 15 Oct 2024 08:10:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DD9266B0085; Tue, 15 Oct 2024 04:10:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DAFF16B0088; Tue, 15 Oct 2024 04:10:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C77BE6B0089; Tue, 15 Oct 2024 04:10:55 -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 A87F96B0085 for ; Tue, 15 Oct 2024 04:10:55 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id F2F5E8147A for ; Tue, 15 Oct 2024 08:10:47 +0000 (UTC) X-FDA: 82675115586.14.E2220ED Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by imf24.hostedemail.com (Postfix) with ESMTP id C34C4180021 for ; Tue, 15 Oct 2024 08:10:51 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qSHT8ixI; spf=pass (imf24.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.44 as permitted sender) smtp.mailfrom=yosryahmed@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=1728979663; 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=KvE7gAeW8sXhIWJBpSNrJV9X+nydWZGu3u6USXH/JFE=; b=scqzfOfSQ0Cj9Qs7H/3d+JeGupcTXon6gc0UPkGtbunn1nT4d9kEpwjjKN6LnFMlc+KuZp /vK5YNCevVhbdom5UNLbUlpK1xPGGXjY+YBaCX0mR5xx9WMU38/upDs3tej21oGogzsGgd 1nQBRRAk00xIvB6hfYY1oIKjPaSJ29Y= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qSHT8ixI; spf=pass (imf24.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.44 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728979664; a=rsa-sha256; cv=none; b=B+XMZ0z0EPgBwuzI1Zi+hBxi4yWGtSoIPjyXhA3uRNDUHTnQUZmjkoHZ8HneqZLoKn433e kSiiim3mfYXD7XpQxz1CS5YPehyEcsi7ceV+BHvl8oPz0ZvoaXBDLpFFqiYay00ZxDxs88 mOePNqJ0pCRFnsvERA0Z6DWgAUaYB6Q= Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-a7aa086b077so663061266b.0 for ; Tue, 15 Oct 2024 01:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1728979852; x=1729584652; 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=KvE7gAeW8sXhIWJBpSNrJV9X+nydWZGu3u6USXH/JFE=; b=qSHT8ixIk/e5tDMm7Uhi3iRUH+Is0jVUTJQ01Vw44p7bQnWIhxrDQ2XQYShha+oO8D MxghRjXH+2HJLxjckKNIys6irz13wrNt3CyW1W9Yy7UjhaZNHGdnt5Deb6ZgtMGXu3K0 EgeZLOlnHdrkjbptMa7oHwA3rQPJwkqy92QZngaAzZi/pyh2VTEdjpW/UIIjfpPyM0ep PPGOHhpncN/iFsVP57VnK82J0BnQT8mTORhrwryWzBr7/c8BGSxM+1rXDQkMF3ERquCE sVwU1cEPtKuTSdymBrDgNrGMgX+JTujE0j9jIZDg18VeTagftfv3LnYO8Vj2Kl4I+3WX OblQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728979852; x=1729584652; 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=KvE7gAeW8sXhIWJBpSNrJV9X+nydWZGu3u6USXH/JFE=; b=D3D6lcgn7ZV5CxloqzJHZbATaMSrjdYlwvzapXGGt3EabdtxAQJxIbgL/ORsdcP1BY /2nQDMKuP5d4CeFSEdmcvX8vAQ029NgUhfSan7XmyChUByTSp6DbbvG18XIsato6tFo8 XGeaq8ctbKRhc62MnldV7l34hIgRrYYrHy0LvHZbCFhswgwTtVUnlJelqHiCyzAtP5NO cbs6s2FgaSWwVeXTOg2IbK1S8IxvIhY56bjQd+PDTSfAMCk4ty2I6fcVomPJpBFHhPy4 W+36QP+DpQy7xF/npB8ns6qksYkc4k7EYL4rImvXxop3LkmhAeJ33243eqRl7pr+S4Ti BIrw== X-Forwarded-Encrypted: i=1; AJvYcCXHYu3tnm4XfkRsc4yy63t/vBVFzgvMkUH+VwjL50HCbyhZI+jgHlHfcjOPEH85bJIWWHVgd3qekQ==@kvack.org X-Gm-Message-State: AOJu0Yx0Wo/Mo76hxpR8LWLMoRJhw90MYJfOtMWTHVKjWXHrgb1gy5fs a7bUPGnfQun4i9jhPa7sxGhYB0kOwNMIaCtRXwlEBA+hJusQmk6KhgtRFO+5bhFEOEQrn+zCbK+ gB6tqvMhOTguw/hbICz2+bGcTTrijacqDbSwm X-Google-Smtp-Source: AGHT+IHj3pap7JooFFjvVueeXA2+cvcJjG4tmLO9wFNQuWlLuixkFRBrdGwr8xAFLl+BwvBI0CIXr/tQT4JW9Ohs+5g= X-Received: by 2002:a17:907:7b8b:b0:a9a:2e12:1a06 with SMTP id a640c23a62f3a-a9a2e121be4mr61446266b.51.1728979851608; Tue, 15 Oct 2024 01:10:51 -0700 (PDT) MIME-Version: 1.0 References: <20241014203646.1952505-1-surenb@google.com> <20241014203646.1952505-6-surenb@google.com> In-Reply-To: From: Yosry Ahmed Date: Tue, 15 Oct 2024 01:10:15 -0700 Message-ID: Subject: Re: [PATCH v3 5/5] alloc_tag: config to store page allocation tag refs in page flags To: Suren Baghdasaryan 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: rspam06 X-Rspamd-Queue-Id: C34C4180021 X-Stat-Signature: 64h1dinw861no1up65zkxun5boezu3ii X-Rspam-User: X-HE-Tag: 1728979851-51372 X-HE-Meta: U2FsdGVkX194kwvGWGUbWyTB+Mh00gWy/HfJB6l5Ww4h0t68HVkf8YCAV7GulTHCfPbAUlmiX+B9nyD9//lqB/hsjFzaWwUbczrX6JpyKNCqRunSc8MBBMkrJQFz42nGqCb32ixvIo8gHUn+I9tYoOORUnva+YFpxQRf9xiHWwe8NOOHhhb/3D55B76snx/suTAGfZBbPGgMaldxIPJIagt7NqEOlrFqackyNbr0J0ooyiiRuFz9S+WTnXdJD3CmGA4lOO1nL8Vjb311aPOcOu6Sx4yI4F48NadlBYOr5T9xtFwM2pTKZ56kqK4PH7wgEnZN0eyPSkHA/Fi+b/gul2roNt+BKYbawwiO+k1Wkka0wgJQ2eOftnChLvhwhjyESUcfIMgrLdj9jsSdu1Bp+w84WzNSS81cWISZHM5TrTNXGbvds10VNF5wddcNP3Bln3KEjCgq/+3oQ8GxCiAQ9X7Gxn7QZ9zMwkHaWQUGK2tE7dNVNKZH4TwA10OfFao/AGayo9HjeTMdfUP7vzSIkdY24LkihAxgsLcUBrsVFO+9DoLTuFC6sKv1JVmxnL4L4sWusQXQR9dUDu/YqI+la5YC+JqFDy9v4luFydJneyiWzevfO4+u6b/qQCDww2H2PEJGwxUq3q/fX2FqLODFG40SSk4nPZzVwsu8oCAnHbcwc+h0w/QCcwki/tcCCa/eUf9uoxGbAn1SGvOjwqApc7Ld4hs76ssMRACZI785oX3xrypTuMumV8qP/rguhjaffA6niKSLxeEdjhbyIPAEGSKft5/Qzjo+UcKXJmCeQvKUObRuQy+7MJCCDQ1Xok+bzkdLaURc7tiiElVvH4u8macjut8ar92+2sTD18aZT6RFiznIDijkGKMRCLDqo52ciVXsSog4QeRuFiBkft4zMat2i++/aCrQdJLRczMtUwO/k27RWQcodsYXGbSg34AvyeOjg0QCo2EHbPGi46y Jdi7mG4C CRn1tA3JKc3+7oSvOA8nk1EKzYW7urfryWjQTW0cnVnItqDm7Ar5j1U8Z5rPQhcoauqwHKd99M5YXnjWVO+v6/6wwIZUCwUAklRZH5QAnmfg948KMcroBLxS4vBYrt6kCXtxTh445QQjB1yjSZtLmPJ/g4S89Jf5pzqZkAckaXosqycbEEBLiH4+gjDQ3JDfUDmRGU8WlmROJJsc0Cqhym9P3OogHL72h2hmmXh0pz3mvqzdAr1lIOZmqKZqg1fIhb8K6dzac0/I4M3bRR9CBsdhN2Zg5RkopG0GROiEYPUQ1t4CfjaS050WI5Q== 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 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 b= its > > >>> in page flags, why not use them automatically or fallback to page_e= xt > > >>> 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 tha= t > > > 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. > > 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.