From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 668271DEFD0 for ; Wed, 4 Sep 2024 16:35:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725467742; cv=none; b=TJRF+kMOpg0E9e188wvmu2bQFFCxqC5CPW8OZ/v8vVqibk+UfvaTadHeqiNB8yIK78LjC8rqjQRlfx9diBhFJmKXaKl/9t3+AI2UKIoSvDbn4g1OxEBIaP1v0bvDSiILH7Al1qqhiqZL8dclH9xVZpi84+3JG0/5GPelphm0T4w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725467742; c=relaxed/simple; bh=jjSmm3IMrrNj7/yAkHdR/SNScgpadLXLJ9+wQvAD/oE=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=TuI56jCuytX5pj6voe71bDlKVoyrCbvIP1QXV9teWd3vmXM4apMeJ6GR8aGbtVmIsP+vNKY83qeyGgCWoGdXLkYTUEXSkJCM8T+o/ljfya6HUwWGDigmrxLRI+pMUols1KjRKtha5mgu7bLNLOYCBv1G7cY6YQ5po4ONYcUQy5g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=4ltTx5rw; arc=none smtp.client-ip=209.85.160.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="4ltTx5rw" Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-456871a4d8fso2571cf.0 for ; Wed, 04 Sep 2024 09:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1725467740; x=1726072540; darn=vger.kernel.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=CVVWyulqkWcIIt3eaXgVpDF1IQ1j/qkoZQP/yErWHv4=; b=4ltTx5rwoiymj2i5iNgvtgATQt+lcOHKEkNw29JggmO8sGgQpPJFTJxLllCuB7sk20 ztdRkKaLPjfttKex+EWnPGoeczVweLHKWRHAWbH3GXHL3yv6EWPoh9VkN7lIMaPJRP5Z OV0WOoC0dJohL8lsFK1BYR7t1VVCMvFO79aQBI+fQo7qcyzUuyCBkTO2v0v3SX9h/ZD6 +JMrsD0Ve0mrlIrgjhpEZ7N0T61iy3Qu9W93WxHbD1V56ddf+4wLgbQYS9jeA/0FTVza ToByxofhNmnVQgI6TnoJKbyRv5DLtwD0i3IYbQvIdzQnhMCkd3nBTbMFkmLIktm4QsEF NNMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725467740; x=1726072540; 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=CVVWyulqkWcIIt3eaXgVpDF1IQ1j/qkoZQP/yErWHv4=; b=l9XJX3qAol74lzQDLKcRHrU8jrKjOYH5ua50tGAFPdMkZD3wwt+7JSCmi+nm1FOPTq pajpWFXzWYnrW/Mi6yQYXGr4Y+5+UdY/55Dct42E5x8DtDZzm96H1OGgGF7EJ9QQaWmN +M5aIBPZLDZnnXNeDwRm826iv2j9dBadLioUr2VnYXDNV8McWRmWDb+VJJnu5Qy0aLZt BK0tEQCBS7KwqGb2lRe0MlrGiuJXrLQ0OQHYAZrhYtM1JjqDwez0bOO+UO9TO78coD0p liR0MN8VA9a9Jc6jstzoHxil8KYt4feDGXzYx2CUpUSzSt3yPSrCDLyf3WL7/l/okSon +RfA== X-Forwarded-Encrypted: i=1; AJvYcCVLMgYe0mn84mUZrzkbZ8WyzkVKXvx++DvhDUEuoAwkfmcx0UEqsJJ9kdx4ND7N1VIs8FJPpoQLOuKNC8a8@vger.kernel.org X-Gm-Message-State: AOJu0Yx/Il84ADJHmxk+2KIXUcVSiud7DVu2cO7nINmShkeyxFIM3Lqg zxo5TLP5Dfcce8L2wrnKkJAQnXCwpqXolM4/TonMv5ubO2Y3OWUv95J72cbL7+0nWf7lio6XMQg aXoqhy1WvOBvSZQ/Qfmr4ZWMZgbOOerAUi9Ys X-Google-Smtp-Source: AGHT+IFRosENkf6QvFVAL8Dd3CPNJYACxr4z2huPX4vhkPrrEkzPkP3ySL6yLGZMIV2DOLm7ZQ5Q5fQT5hqm0DOdCB4= X-Received: by 2002:ac8:5993:0:b0:456:7501:7c4d with SMTP id d75a77b69052e-457f7afcf16mr3378481cf.9.1725467739803; Wed, 04 Sep 2024 09:35:39 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-modules@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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: From: Suren Baghdasaryan Date: Wed, 4 Sep 2024 09:35:28 -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 On Wed, Sep 4, 2024 at 9:25=E2=80=AFAM Kent Overstreet wrote: > > On Tue, Sep 03, 2024 at 07:04:51PM GMT, Suren Baghdasaryan wrote: > > 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 th= e > > > > > > page allocation tag references. When the size is configured to = be > > > > > > less than a direct pointer, the tags are searched using an inde= x > > > > > > 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 ref= erence. > > > > > > + > > > > > > + Smaller number results in less memory overhead but limi= ts the 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 y= our > > > > > own". > > > > > > > > > > I pity our poor users. > > > > > > > > > > Can we at least tell them what they should look at to determine w= hether > > > > > whatever random number they chose was helpful or harmful? > > > > > > > > At the end of my reply in > > > > https://lore.kernel.org/all/CAJuCfpGNYgx0GW4suHRzmxVH28RGRnFBvFC6WO= +F8BD4HDqxXA@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 w= e > > > > 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). > > I see, it's not about the page bits, it's about the contiguous array of > alloc tags? > > What if we just reserved address space, and only filled it in as needed? That might be possible. I'll have to try that. Thanks!