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 62493CD37AA for ; Tue, 3 Sep 2024 18:20:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 938988D01C4; Tue, 3 Sep 2024 14:20:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E8F08D016E; Tue, 3 Sep 2024 14:20:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 789AC8D01C4; Tue, 3 Sep 2024 14:20:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5A0418D016E for ; Tue, 3 Sep 2024 14:20:05 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id E4120A8D7F for ; Tue, 3 Sep 2024 18:20:04 +0000 (UTC) X-FDA: 82524241128.08.9738577 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf08.hostedemail.com (Postfix) with ESMTP id 193C3160003 for ; Tue, 3 Sep 2024 18:20:02 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=D72TEFdj; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of surenb@google.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725387533; a=rsa-sha256; cv=none; b=yWFQQI8uHiQXRdZMPk9sCFO4ST4KNKC5kOLrT5vkUEgHhMRrWkKHNkia2Potew+ioHoPAm ndWQAyCe2nKmo8UqXC6IfPX7ao+rcLsNt60zttzgsRsfEiZJLKPXIHyi89FM9+OBS/8pVA OEA/4ZXSC5ptUOabpTOWIN95U62pMf4= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=D72TEFdj; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of surenb@google.com designates 209.85.160.170 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=1725387533; 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=BavSPl5fUtSdj/rsZpwNTR+qZ+A98RwNx6tvieBDuTs=; b=wKKaISZnLrYj7bwO0UCZSChsszhIg6hmZriP+N2E13QDpgGP8XC5plVaEm/KgOy9e3zVZs 9E9e3DEq3bkBiqQADEuEWYDpGE3dUacyR2ik/AcLMR1oIIQKJopFNpqAdMdezC2Acpm6KE z/xY6tlpMajdnZ7UlH/fn2t354yQ4oI= Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-4567deb9f9dso32861cf.1 for ; Tue, 03 Sep 2024 11:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1725387602; x=1725992402; 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=BavSPl5fUtSdj/rsZpwNTR+qZ+A98RwNx6tvieBDuTs=; b=D72TEFdjT7NjdQouL5tZzIxGkemSdkqRSaWz5Uwt+3FQp3n7G0WZ07v/2BYmBPPCai 9MLdb87MN53VQGpSoAL+MF7b+iHZaMy9VdU0ZksFqXjiY6Sxb7mjObvnvs489H6sIn7U bBaiaQOfZNc8Z8+W+GKvM+Uyf8AjQI0SuuLXzrBngevH/iYB0b2g20FKUQs3qD++mPco 9eTyQyxfkrru9EfU9aluXBHVh3xyIpyvNyZKe2XpIavRpwQlkDan3CQ+MV2zwsl/pVwk mzf7qwBzhXloxHzqI8X9MZXFgeKueDAZx5DFeQpvzgbwdaoSpDpGfmETA/2qEw+fWU9b XQPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725387602; x=1725992402; 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=BavSPl5fUtSdj/rsZpwNTR+qZ+A98RwNx6tvieBDuTs=; b=bAsLHvbLYLzgS+gcgV7oMZKMJxkbC184Dtt6cNuXPj3IInSYRUko73uiGSqjAvF/cP zSuu/c54dy/g5rrE4db/TqztAV3sNweGTJsXyHOIPKXKEdQoBmVF8bVrsxI5GhuXHRtf RDnxw7fH6zZPlJtYRGi2RNrZVK6AKJRpY3IAPaA4gqzyOHGCPK1oYUS/lCL/VDAXxz7S Kc1odi03GkMw+kNuALrcifOhgAUS4L9WPdYsZs3tJWsXyxrjv/2dAW3fdy0GiSy02Duz 7p67YDXknGk4XOrfjrG4sTdPAlRtziiapXAz/wE3j/mzse8bLpOHW3mswE4LCSZPJiTB uTkA== X-Forwarded-Encrypted: i=1; AJvYcCV0J4jCqtlkwkT6dbs4VkW6zYKFuC7j8zCHN6HTQU0sNWxGQMQosjTf7Zl/RXzvU89vHK/ykBbQKw==@kvack.org X-Gm-Message-State: AOJu0Ywn6IfURCXkpbyUsdoeiWd0uOiS3Y8hsoASwY8Aksu1aQL4sixP vvl1hbMcA8HuSMhIUoONJPOg5mu6qhO4UUR6z6/+6e9R7lyOzHNphckcrwd/RxDDOs1V6qmmY7v lW591WkO5rkkrUmJgmCz51vxNYLdZDYKXOty5 X-Google-Smtp-Source: AGHT+IGGVsLSR0VWiAw1Ihng2p7h4/4G9uaafKrLUqbwk2Hx9YjWEaRA9FJvSAxgGPWu1F5yx8Cnzf/j56ZBNxw7Whk= X-Received: by 2002:ac8:7d85:0:b0:453:56d3:d155 with SMTP id d75a77b69052e-457f6225901mr370451cf.8.1725387601590; Tue, 03 Sep 2024 11:20:01 -0700 (PDT) MIME-Version: 1.0 References: <20240902044128.664075-1-surenb@google.com> <20240902044128.664075-7-surenb@google.com> <20240901221636.5b0af3694510482e9d9e67df@linux-foundation.org> In-Reply-To: <20240901221636.5b0af3694510482e9d9e67df@linux-foundation.org> From: Suren Baghdasaryan Date: Tue, 3 Sep 2024 11:19:48 -0700 Message-ID: Subject: Re: [PATCH v2 6/6] alloc_tag: config to store page allocation tag refs in page flags To: Andrew Morton Cc: 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, jhubbard@nvidia.com, 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-Queue-Id: 193C3160003 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 5npc9tckmnnjae8xh6yrkutugxqayp94 X-HE-Tag: 1725387602-598209 X-HE-Meta: U2FsdGVkX18scDY9cilpb2ZS6yQ/UGm6UDi/W1d5m7pDODixjXbuLMRwV4itnNKAW14szUQByoQQXR5i+/DhDyJQPRmmaSH4jxD0tRgCwAnegYZhnXLofPBsG8h1pdHMP4Q6k41Hf8OtZ2FUSqqEwXGUXOIJyGDDbqKeUQxswB6m85b86UD98dqifPI4yjTcXa4ibR6sXnYtbrh4m6fmwPrQ3oj4kIC0MwCFwC4DsNxUWcJV1zpgwnwaGXcGDTDWUp3j4tBVhmCqxwaJVHq7Lc6vO1LjGDQWu8ST4w7Us1MLIAKCAXZ/h7NZ7vznjsFgD/bqr0FbJH8rQIK4Zfh1V68XLvrkDy2jux3APqSb2Njm/dHJ+ZW56uB6QvXVoR6SvzQ9LZ7lwXBbUhZyMETjPgZxQOoEZkjZU0DEdOW+PkcjTjApsDJtpjbGioRK/0trOe1AiOyhQxrjc7uaDmo0yxyF3wBo4jankr3HbmfH2IkhgbkM4KNbsiuq3yl6AhsIK5Is63NF71q6W2SDwWnlvcg3HgffuW7rHasFz/grSoQm6GF9rQ6fvP9/VdYldxAvy8M4JdqifE67cY4cN9JOEsmT/jA3d3VPw2o0XHW2gVbNh3Fw06auXQ1ffkQsI+nmP4f/Nyi5STbVp1X4s8dSCg8t+wOLs4k/zIgAw3l9inkNjsJXAZDmrJxH5rbV3aAih/bTvBMM1B1+3X595MqqO/zLSN9bBpacL9L3/vM6oeokCPz6J7KJ2Vb7OtEfmyqjl5wwKqQAahEQqzkk13vvpxKMEfp5NkG67F4KNtePpxHNULbTVn0FaqFUPWL8c+dpqyStreynxcLfxqfwTKzZjolXNmIY9FuG1VmwT8EWyMeSYmA0jQFmaykb4/nw0mqU1THkmor/VEVlq0um7kheF6BPyQtvQ3PJbTkn3axOekZ34dcN6kOW5rmHSOr5LOPMBiDRijgo0x1JbQrV5YE LEXviNpX y3J5uECDU5fnRBI0iCx9Pwkscw7saLDdZUWVLTDkryGzWI3giTP0M1tpDQhaGesZ7csYtrSDomBWEHRb/BAFvE6camzHnRqNkltf8FAoyAn+MWhDAqQpSD7ObMJd0P3smoFz2SwEcgrAveqLTXzjr/iUkfQFQeJz60AFFle54i7U58Ete3iJO/3NSLH/jOV0mzv58a6Tc2ovCfAzk8r+m7udoKKldDMi7wxF46/vEQTZMnebYaoMFLUmD63mU8bZYGtoYvQi80ljMvtKZ6A/lRHCROjeha3MRz0HoMThMXZKEj0UrFmiaAfonr4eXMrS4KHNeMSqbBl/ctqDqWXEwE5G2/8go3KS81JrE8HFLC2MBoa1o2LHR0reYcimtAyztL+UZ 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 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: > > > Add CONFIG_PGALLOC_TAG_USE_PAGEFLAGS to store allocation tag > > references directly in the page flags. This removes dependency on > > page_ext and results in better performance for page allocations as > > well as reduced page_ext memory overhead. > > CONFIG_PGALLOC_TAG_REF_BITS controls the number of bits required > > to be available in the page flags to store the references. If the > > number of page flag bits is insufficient, the build will fail and > > either CONFIG_PGALLOC_TAG_REF_BITS would have to be lowered or > > CONFIG_PGALLOC_TAG_USE_PAGEFLAGS should be disabled. > > > > ... > > > > +config PGALLOC_TAG_USE_PAGEFLAGS > > + bool "Use pageflags to encode page allocation tag reference" > > + default n > > + depends on MEM_ALLOC_PROFILING > > + help > > + When set, page allocation tag references are encoded inside pag= e > > + flags, otherwise they are encoded in page extensions. > > + > > + Setting this flag reduces memory and performance overhead of me= mory > > + allocation profiling but also limits how many allocations can b= e > > + tagged. The number of bits is set by PGALLOC_TAG_USE_PAGEFLAGS = and > > + they must fit in the page flags field. > > Again. Please put yourself in the position of one of the all-minus-two > people in this world who aren't kernel-memory-profiling-developers. > How the heck are they to decide whether or not to enable this? OK, 59% > of them are likely to say "yes" because reasons. But then what? How > are they to determine whether it was the correct choice for them? If > we don't tell them, who will? Fair point. I think one would want to enable this config unless there aren't enough unused bits if the page flags to address all page allocation tags. That last part of determining how many bits we need is a bit tricky. If we put aside loadable modules for now, there are 3 cases: 1. The number of unused page flag bits is enough to address all page allocations. 2. The number of unused page flag bits is enough if we push last_cpupid out of page flags. In that case we get the warning at https://elixir.bootlin.com/linux/v6.11-rc6/source/mm/mm_init.c#L124. 3. The number of unused page flag bits is not enough even if we push last_cpupid out of page flags. In that case we get the "Not enough bits in page flags" build time error. So, maybe I should make this option "default y" when CONFIG_MEM_ALLOC_PROFILING=3Dy and let the user disable it if they hit case #3 or (case #2 and performance hit is unacceptable)? For loadable modules, if we hit the limit when loading a module at runtime, we could issue a warning and disable allocation tagging via the static key. Another option is to fail to load the module with a proper warning but that IMO would be less appealing. > > > config PGALLOC_TAG_REF_BITS > > int "Number of bits for page allocation tag reference (10-64)" > > range 10 64 > > - default "64" > > + default "16" if PGALLOC_TAG_USE_PAGEFLAGS > > + default "64" if !PGALLOC_TAG_USE_PAGEFLAGS > > depends on MEM_ALLOC_PROFILING > > help > > Number of bits used to encode a page allocation tag reference. > > @@ -1011,6 +1027,13 @@ config PGALLOC_TAG_REF_BITS > > Smaller number results in less memory overhead but limits the n= umber of > > allocations which can be tagged (including allocations from mod= ules). > > > > + If PGALLOC_TAG_USE_PAGEFLAGS is set, the number of requested bi= ts should > > + fit inside the page flags. > > What does "should fit" mean? "It is your responsibility to make it > fit"? "We think it will fit but we aren't really sure"? This is the case #3 I described above, the user will get a "Not enough bits in page flags" build time error. If we stick with this config, I can clarify that in this description. > > > + If PGALLOC_TAG_USE_PAGEFLAGS is not set, the number of bits use= d to store > > + a reference is rounded up to the closest basic type. If set hig= her than 32, > > + a direct pointer to the allocation tag is stored for performanc= e reasons. > > + > > We shouldn't be offering things like this to our users. If we cannot dec= ide, how > can they? Thinking about the ease of use, the CONFIG_PGALLOC_TAG_REF_BITS is the hardest one to set. The user does not know how many page allocations are there. I think I can simplify this by trying to use all unused page flag bits for addressing the tags. Then, after compilation we can follow the rules I mentioned before: - If the available bits are not enough to address all kernel page allocations, we issue an error. The user should disable CONFIG_PGALLOC_TAG_USE_PAGEFLAGS. - If there are enough unused bits but we have to push last_cpupid out 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. - If we run out of addressing space during module loading, we disable allocation tagging and continue. The user should disable CONFIG_PGALLOC_TAG_USE_PAGEFLAGS. This leaves one outstanding case: - If we run out of addressing space during module loading but we would not run out of space if we pushed last_cpupid out of page flags during compilation. In this case I would want the user to have an option to request a larger addressing space for page allocation tags at compile time. Maybe I can keep CONFIG_PGALLOC_TAG_REF_BITS for such explicit requests for a larger space? This would limit the use of CONFIG_PGALLOC_TAG_REF_BITS to this case only. In all other cases the number of bits would be set automatically. WDYT?