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 8AE60CD37BE for ; Wed, 4 Sep 2024 02:05:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F5248D0211; Tue, 3 Sep 2024 22:05:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0CBA68D018A; Tue, 3 Sep 2024 22:05:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED4F48D0211; Tue, 3 Sep 2024 22:05:06 -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 D10F18D018A for ; Tue, 3 Sep 2024 22:05:06 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 787B9160B62 for ; Wed, 4 Sep 2024 02:05:06 +0000 (UTC) X-FDA: 82525413012.22.23760EC Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by imf12.hostedemail.com (Postfix) with ESMTP id B64A340011 for ; Wed, 4 Sep 2024 02:05:04 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=fMBXywEz; spf=pass (imf12.hostedemail.com: domain of surenb@google.com designates 209.85.160.171 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=1725415457; 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=mCyPy6iwCP5CjIg/B3ozt0KbGUw/B0FCHsUaXuPiqn0=; b=Sc5MgF+ru77VHnjRTE80BoPjoefjUDaFKqZgsSSiSC4TZZA+TUikZ14Hj30yD5sXXN7dSw qYSiPRl4ChUbk6nGWu0PgkRmd4X0cNMv1ychvOXZ/3F7uZJ8j5iMl3EXPztRk2azFS/5Zi UZ2zgbqbvAV5l9AvW1XOkpI/6cms1ms= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=fMBXywEz; spf=pass (imf12.hostedemail.com: domain of surenb@google.com designates 209.85.160.171 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=1725415457; a=rsa-sha256; cv=none; b=ZgqUOKXXIkpNI+i4SYiIbsAtbn5L0v+Hxe3kwOsunsplCiIYVMGnqDA9C8d2M3E/yGAayr lWoVT/o6NBxixpyhcB4eersA53KHtLPcpWiZ0tuRu9T3Y8x8sx6YLhi7ZLl+qo6HdT3kvn 1pNsHyrDIAhq7dnOle/WN0Q/5C02hLM= Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-4567fe32141so88281cf.0 for ; Tue, 03 Sep 2024 19:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1725415504; x=1726020304; 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=mCyPy6iwCP5CjIg/B3ozt0KbGUw/B0FCHsUaXuPiqn0=; b=fMBXywEzYCIG501YvQDpbFT8HzQEkWeb0mVxhn+2Lx9Fk7kGfB/uNhluQosAYuRKf7 WpUCTVD7nYTbZaiwiBOoK9CXAY9W41bReYLkvpmQVqA5Ya8EK0wIondZiu4ma4kNVces LmcibCqDXffBgwfZfZK3H1IgZvybA+OKbdfJGmxPcZJjpnhrV1/yXqmS0RwuUz3g+7LV C9M38o4M9EpDP1pI70mQFS6d5nqsuVoKPQSe2fA8F75zs4PN95Triv85cnOIktzzK3bJ B9sFwGG9lTD4E+xjqk2e7gM50bGVDyXCav7Tt2lCoYf5rj55dyQsICDHU4LH1N5Z1Q6d EK5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725415504; x=1726020304; 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=mCyPy6iwCP5CjIg/B3ozt0KbGUw/B0FCHsUaXuPiqn0=; b=R2gOrG2aEmAX1oZ96iQuX1uAU2+nu86AMT4nok/kMmgiRQ9YMaU46aNHcmVNxZxRYz 7feA8jaj2obMxtH3yGeDoXnk6nYVBLaTPeKqMLa0OOrMGe65V+ynfroNtl7XtA+g1UNj 9/c+JGONvvIQbqKZLzkiTU/ZQ/4obZJsiVF+dGYEunu8GQcpTQ193ole4Y5LhmR8EIfh EYxp05JfYzTBN7vw2JdbIZOqRftEfybzjDG2HpsFQ9x/e5dAtPDuRYbetZ2SQPAUHFIH p5o3Nao/UXaOJ0KUYRFk8SxYJAWMo5KRSte/Jt/dB/+zuLzw6Q6XLfytdS68lZUzt91X ooRA== X-Forwarded-Encrypted: i=1; AJvYcCUZxDDqbh7ixW9Ig7GzVsPDq37TMlvf0OpE7mfq79Lk9IslAuql+bIvJZYetGof4xvsHCTltJmfng==@kvack.org X-Gm-Message-State: AOJu0YyHBUGkeW4PdigobE4tm7Bg6WGn5JTIy/QaeJaiBH1sg6cRefNR FUwGah8+FqdX1GhPz6T6dMKwXZ51bH1RbgbuG4aYbBgkptBdTmD+6A1530NjNgm3Na7n5jgv+0I +q0hcKunlP0pRimk6GCj9GJp5UQWW3Xz+j89l X-Google-Smtp-Source: AGHT+IEbZycTL1qRNduokmk2dFqgQ/aI0bamoSE/FU7WW+tZXb6qMK7tmdkD+eHzjSLi5+cwNQdZLetM5UhjTGy3xjQ= X-Received: by 2002:ac8:5953:0:b0:447:f958:ab83 with SMTP id d75a77b69052e-457f7b3648bmr1045391cf.21.1725415503320; Tue, 03 Sep 2024 19:05:03 -0700 (PDT) MIME-Version: 1.0 References: <20240902044128.664075-1-surenb@google.com> <20240902044128.664075-6-surenb@google.com> <20240901220931.53d3ad335ae9ac3fe7ef3928@linux-foundation.org> <3kfgku2oxdcnqgtsevsc6digb2zyapbvchbcarrjipyxgytv2n@7tolozzacukf> In-Reply-To: <3kfgku2oxdcnqgtsevsc6digb2zyapbvchbcarrjipyxgytv2n@7tolozzacukf> From: Suren Baghdasaryan Date: Tue, 3 Sep 2024 19:04:51 -0700 Message-ID: Subject: Re: [PATCH v2 5/6] alloc_tag: make page allocation tag reference size configurable To: Kent Overstreet Cc: Andrew Morton , 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-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: B64A340011 X-Stat-Signature: 1kc9f3gj6pjnibyc4bwggx1uzn7m1den X-HE-Tag: 1725415504-245766 X-HE-Meta: U2FsdGVkX18F1qhiJHyb4WnnkGH6SJniTY2KfWbswil1W4spSZAZ9oMTAAE1R67tV9J3mDhgqzZPp3UxvY65UsOGyz/Iaof9oteyyVb25ubKQ1YCuXN2quZry6n7jAwHthgnCm4qx8YoNVmXm8hNBClF5m21wLM9pctRMmg+1QHmCuGey4tt6UEX/9y7s+ynpGgrTvLIzQPFFCwJYzcXtZK9eBfVU08cMvEss4Br0eG2h/l2bvkxqfvLDcGREwTxZfiXmGiaA0htunNAdtUSPVf5eBk/fuE8D9nFWwRsZ+ZTtnSH8Kh2nNa7bkE2GB4Ox9YN0NiLB74jfXiDKVLNdRLjGjRrEmWfhrnT+9IIE688P9tU8SGBlCy/bWeLMHCSdi3CpY6nDpWjY3R4ET4moOCzo4RFuo1+P4uHPnjimi8eMxOzeeRm8ZBWUPp681H8QcNXVvCxrvE4RwcbbKNh7TvY/wWWQeqTcBCswT9J0u5sYVVPkJtXtY/ogfVIhAage2JXCcHUt0IFHltGqOA8fVq7s4FBUHT19WYTCLJ+lmYwR0hcbZsnOg+GG1pql9Vee6Gw5J7HAnmP5TXgjdqFZxB5ch/eTXYwhiOeoTV7x5vvRABuISv2adyRMK+iD121uD15gXhc45MIjyriXGCJ+hGmrg7Q6vs7M9+UsPGJxHkElEjLk4mQ95MNAM2LaLcR4vyEnQ4W2w+RSdBlrKQpVXFKRyQqSQJcv1XkyuvEbZ9OkJdqt2nmrQYEztv66veOJal8hnAGOH86eA/ovS5+20t5xO1HzcR+ORO2f6DFuv8ACRLef1I9W3W5u3W4CGAg9bJ5IgTEUZUEtm67JoqjfyowN4rNEw/Si/jk0UKEtjujx4jieROy+AcGy7Ru3m4u/+vnCL9+dnH8LblvhdLsJ+C3NisNTInGKocyao8/NZ4ZGSnlRUIVr+KtvwNqrhg20h8lBVH4bgHdZSUuK20 C46SqJZa 4KyeviZqwk4EkO7griGSC+JC8FcQNUyryxHC9YzDnmcBbwG7pJpeiirhVSJT9KV90fEILdEvxqDv2Kte9VKfRLMrdioz2s0sQf3si8G61ahjQ64Oaks7G0e6bmmBO3Wogo1NTMZJQtHU/UJev4e68z1NhUE0twdQIlZhaFzFrDfwg8QxrfdIszNqT3hYR44VL6roCNu+y8fF6f/TrQG3htTQD7/UwTaEMI/Jew+ipiBJSqfl5QCdto8PSPz9Zfc8yhQe/U0w22Wh+HyC2bl0YoQ2ecfh4IijVXybepR7XWZht7oqScP6LCqwNRyvSbaUq8rdSvpYFAbWKc8bJLiwtD9mp3VG57vF0bfCJMdKJj3cNphrNXxXung5p3g== 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, Sep 3, 2024 at 6:17=E2=80=AFPM Kent Overstreet wrote: > > On Tue, Sep 03, 2024 at 06:07:28PM GMT, Suren Baghdasaryan wrote: > > On Sun, Sep 1, 2024 at 10:09=E2=80=AFPM Andrew Morton wrote: > > > > > > On Sun, 1 Sep 2024 21:41:27 -0700 Suren Baghdasaryan wrote: > > > > > > > Introduce CONFIG_PGALLOC_TAG_REF_BITS to control the size of the > > > > page allocation tag references. When the size is configured to be > > > > less than a direct pointer, the tags are searched using an index > > > > stored as the tag reference. > > > > > > > > ... > > > > > > > > +config PGALLOC_TAG_REF_BITS > > > > + int "Number of bits for page allocation tag reference (10-64)= " > > > > + range 10 64 > > > > + default "64" > > > > + depends on MEM_ALLOC_PROFILING > > > > + help > > > > + Number of bits used to encode a page allocation tag referen= ce. > > > > + > > > > + Smaller number results in less memory overhead but limits t= he number of > > > > + allocations which can be tagged (including allocations from= modules). > > > > + > > > > > > In other words, "we have no idea what's best for you, you're on your > > > own". > > > > > > I pity our poor users. > > > > > > Can we at least tell them what they should look at to determine wheth= er > > > whatever random number they chose was helpful or harmful? > > > > At the end of my reply in > > https://lore.kernel.org/all/CAJuCfpGNYgx0GW4suHRzmxVH28RGRnFBvFC6WO+F8B= D4HDqxXA@mail.gmail.com/#t > > I suggested using all unused page flags. That would simplify things > > for the user at the expense of potentially using more memory than we > > need. > > Why would that use more memory, and how much? Say our kernel uses 5000 page allocations and there are additional 100 allocations from all the modules we are loading at runtime. They all can be addressed using 13 bits (8192 addressable tags), so the contiguous memory we will be preallocating to store these tags is 8192 * sizeof(alloc_tag). sizeof(alloc_tag) is 40 bytes as of today but might increase in the future if we add more fields there for other uses (like gfp_flags for example). So, currently this would use 320KB. If we always use 16 bits we would be preallocating 2.5MB. So, that would be 2.2MB of wasted memory. Using more than 16 bits (65536 addressable tags) will be impractical anytime soon (current number IIRC is a bit over 4000). > > > In practice 13 bits should be more than enough to cover all > > kernel page allocations with enough headroom for page allocations > > coming from loadable modules. I guess using 13 as the default would > > cover most cases. In the unlikely case a specific system needs more > > tags, the user can increase this value. It can also be set to 64 to > > force direct references instead of indexing for better performance. > > Would that approach be acceptable? > > Any knob that has to be kept track of and adjusted is a real hassle - > e.g. lockdep has a bunch of knobs that have to be periodically tweaked, > that's used by _developers_, and they're often wrong. Yes, I understand, but this config would allow us not to waste these couple of MBs, provide a way for the user to request direct addressing of the tags and it also helps us to deal with the case I described in the last paragraph of my posting at https://lore.kernel.org/all/CAJuCfpGNYgx0GW4suHRzmxVH28RGRnFBvFC6WO+F8BD4HD= qxXA@mail.gmail.com/#t