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 564D8D3E18D for ; Mon, 21 Oct 2024 07:21:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8A7476B007B; Mon, 21 Oct 2024 03:21:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 830246B0082; Mon, 21 Oct 2024 03:21:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6AA3B6B0083; Mon, 21 Oct 2024 03:21:37 -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 4F7AB6B007B for ; Mon, 21 Oct 2024 03:21:37 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C66811C6C13 for ; Mon, 21 Oct 2024 07:21:19 +0000 (UTC) X-FDA: 82696763772.21.54893CB Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by imf27.hostedemail.com (Postfix) with ESMTP id 5129A40003 for ; Mon, 21 Oct 2024 07:21:20 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=TgV8WWxT; spf=pass (imf27.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.45 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729495218; a=rsa-sha256; cv=none; b=YaE6jbKHJo6AcMlK1T7kyvWYGV00O8hwsABf9uMViYXCaH8t2WFJMra13fOQtbD8dxy1gk 6Vtl2QwZKXQ4Uyxz5QRvatnaoSJH2s+BSaDuPEdxb/gdHiQBKvDpu6buGw5ssOFpPLozYZ hjc/Dff4s4nXzIphGTqjzZ8C0X18Njc= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=TgV8WWxT; spf=pass (imf27.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.45 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729495218; 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=sM4ACN0kxcjfg5UR2mRm8TYbMyjtVqVwofUPN7ArdNY=; b=OP1bTnM6Gngbz/+D6z/y2QQm6vcBDssNxa+YmbRaET2pi3DxOoxKaL9k5OGDN5SG/NwbW9 Cwz9SiJCtow125rnJeo4ZfpfcRxdcAAZHPsuHg9OJ3SIp1RA6XOmqtBYCJILNEtP7tSU1/ x+bO4JlT9V79350bvqDdgavlDpYdUT0= Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-a9a1b71d7ffso664743366b.1 for ; Mon, 21 Oct 2024 00:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1729495293; x=1730100093; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=sM4ACN0kxcjfg5UR2mRm8TYbMyjtVqVwofUPN7ArdNY=; b=TgV8WWxTJjqrNk7O5AyvK5hJme42ODUGxim8yN8Q90Yqg76sr8JJW3wrVXi2pb1YYR pixSnfvqW+/70qVmwXp5iI7YjhZ03nv6shfqep0c0M1XeAtpohEaTYfgwZVR3aYTnDE9 4E6oSy4E16WwL5ViWoTESIe7rH6FiXdUacgWtXhW99h6OgFVDDIIANBl1gzEocUbX2Fe S5UVQKCfwBXDdO25+eUX1i3M51kRwug3kOngDLNV4suzHOqfYnJKdEF+sq2tzEJWnLZw BZR/k683xnoQ1bDsHCGUcNI6gYneosyppN2A5fS+XSJ63ddS8do8bldwj14W4+Xscy8o q2Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729495293; x=1730100093; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sM4ACN0kxcjfg5UR2mRm8TYbMyjtVqVwofUPN7ArdNY=; b=BvShUG1qt60EnBFnshSvYTJhtDmv2Ln35hlxF4iYbJnOSJe6bZfDIclrrhuAg45Brx B1ZJ49swKzaTvHB57Van0T9MCKU38F/d13cIySWQm6UJMrYdeh7sEn6n7fdADTLRp37g 3UKKminaP10pcDXn/+lSnhis4wTD06HNnYezoNg82C05Cah5yDwIfmgToBWIarfdll6W MAGEubnK1/bLQLjSHojmo3ekj+8HQaZMkLHnyfHOueisED9TYjPCnx7oWYc5RS8uUEPg oG82FtvDpcWyauPaWwz6mChQZOl3l+y8rfw/fUpbq90vdF2uk7d1sR6Gkp+o3AbXO+de ggmA== X-Forwarded-Encrypted: i=1; AJvYcCX0AGmdjVJE7qkoVLsC8vGSsbKVWZ/h6ufK4wIdojjsM6vumOTamITSMIQqGiaBw9L0ONhZu+iQyA==@kvack.org X-Gm-Message-State: AOJu0YzW6GRjc4RnkICny1++JIGhDBYMuQ0ns3VUZIqcNAK5zN8sKYCx 1MukFjqNaJa10eKkpMyzk1jy4qyc/52Fc1IatdI4yYQzxzsXwhSA/YcV2BbtwWs= X-Google-Smtp-Source: AGHT+IH7c0NP6cQiTSwyl//5zHrNCLOmGdFL9dCgtDAoFWr5dtBuuJz0loN2CEAZ3ZOL1zVScXIQ/Q== X-Received: by 2002:a17:906:c10b:b0:a9a:1792:f05 with SMTP id a640c23a62f3a-a9a69ba907cmr1161713466b.31.1729495293159; Mon, 21 Oct 2024 00:21:33 -0700 (PDT) Received: from localhost (109-81-89-238.rct.o2.cz. [109.81.89.238]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9a91559dfcsm167515166b.132.2024.10.21.00.21.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Oct 2024 00:21:32 -0700 (PDT) Date: Mon, 21 Oct 2024 09:21:32 +0200 From: Michal Hocko To: Suren Baghdasaryan Cc: David Hildenbrand , 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, 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 Subject: Re: [PATCH v3 5/5] alloc_tag: config to store page allocation tag refs in page flags Message-ID: References: <6a2a84f5-8474-432f-b97e-18552a9d993c@redhat.com> <9c81a8bb-18e5-4851-9925-769bf8535e46@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: n6pti6ir6hd1znbtnzhnrjojfatijo77 X-Rspamd-Queue-Id: 5129A40003 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1729495280-738360 X-HE-Meta: U2FsdGVkX19yfXqbhxdl76VvCmG80mny3oPui6tNzaCuWouCpEP7sYGO56plK40722mupwNVicOthpYP1Tchb7KgQzaKJmCArDAyn4hMVYy1GcPMSIhpMkA9hwoLc3vsKQ2FVLeJbqH4mjidog2v+ln/SAXAzf5fWo6LJTVFINgECwLJS654/ssyS+0XV/L7v1J2lrMPSbtA8MA6JSNAlADYNkWSPb3DJe7LB9hDjCMmYFfnQ/s7iAr+N0ooVr0Cs1Xu6078T7os5W4g/anHzE0w60nC5wSUjZWHPt27BxtLYD4cfLUWCLyhd0UTk0f/2VWzVOMw6MjJNKga0Bcr0wRPySkK4Ql3t+7ChCsCTtiRb0lGeCs7COhHOmwXZahsTelBOaUfXv/P5euUX/eWkDXhwng34WAwxNjlFcuAqM2m0th+uhnbf6wGeXB+INcTGj84VG74xK+0KgDCwtkvwfugkez5Dzg/oN+kbuSCrvy9qOnOFUdT1WgKQvgWrHxkwiVRLTjgjosOTiyAwN+nmiNMK8Ncq11eTIVolUJdaXzPHkgxpY8DxSSf/xPJtejGeI5yJLFW3pyjZxlB6nWVMsC36y6JNqlu72lSonl5lMF/CKDU2ObK1bZVpCWoy3EpmKrBlrd1wLUgeMvO4VWEhOTPo/lq9cuzdhZv6995XUMeKp+gMKWxGS+0u9d2KoUVC5xsUeg63CT+A4xjKZUc1pAj0KKyk0jVPimgZ58FJZnMFpjHsHg9DOMLIRclOYXiCr3AzuGNXW0iei1ie9zGGGWaC8wJT8H39VuTW2Mw4cu+FJILkwEIL5aVRm/58yjP7BGmSZ1JgWpj4kCHZ2LAR1v5lnpk93lzCO3Sc/2YR09O5Ipk6gQyzZz8B8r4WhBxYFdwdp6x+aTViyZ+/F/UdcU+GnscZNunypPy1uwk4PhjvZzG0Ycgeeyn33OVeESCNtHSM74OD1E9e8nEI+p m+oqiJUo NXBycBUieeWTr5gR5Rez4VVLlv1enZIU2sWXOwrXPXdfwax6vODF2HzzoFGyqdeJixCAHIiIK+wyZeWt9IpVgIXKbah045IP/FPNEwyRLmNFBqaUZR0BOymuiq6KiprzgEd7CEtK1nTgZkPu/awYb+HwHWHTM0l86CWWtZVa1SOdsBdvyd7Bc1abVC4THNa/PqN3bpdP4gK2uv6OroGYLeQpEYXGnEEMBRvWFRZNzKYul1Gznql5Tn9boq6HiEfoxKhvXLwq/tUpps+uihQk/GMPjPvq6rksROlcdugXW0ysMQSM61nnf8zB9eOQtVlv7qgui9h70ceyr9bIqEuLjh05xQnDyVuZ9iSVcWgpWYsyldF3PCW3uN3MjZQzDIsby4qvU5SSLwl3Yaq1q0I5mcHI9+auBNimRlCcgA5K32UEzC2CfajlytPNekeaXRkgAYxJvR3x/XQ1hcmaBdLSDngxT0Q== 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 Fri 18-10-24 10:45:39, Suren Baghdasaryan wrote: > On Fri, Oct 18, 2024 at 10:08 AM Michal Hocko wrote: > > > > On Fri 18-10-24 09:04:24, Suren Baghdasaryan wrote: > > > On Fri, Oct 18, 2024 at 6:03 AM Michal Hocko wrote: > > > > > > > > On Tue 15-10-24 08:58:59, Suren Baghdasaryan wrote: > > > > > On Tue, Oct 15, 2024 at 8:42 AM David Hildenbrand wrote: > > > > [...] > > > > > > 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=n 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. > > > > > > > > I really do not think users will know how/why to setup this and I wouldn't > > > > even bother them thinking about that at all TBH. > > > > > > > > This is an implementation detail. It is fine to reuse unused flags space > > > > as a storage as a performance optimization but why do you want users to > > > > bother with that? Why would they ever want to say N here? > > > > > > In this patch you can find a couple of warnings that look like this: > > > > > > pr_warn("With module %s there are too many tags to fit in %d page flag > > > bits. Memory profiling is disabled!\n", mod->name, > > > NR_UNUSED_PAGEFLAG_BITS); > > > emitted when we run out of page flag bits during a module loading, > > > > > > pr_err("%s: alignment %lu is incompatible with allocation tag > > > indexing, disable CONFIG_PGALLOC_TAG_USE_PAGEFLAGS", mod->name, > > > align); > > > emitted when the arch-specific section alignment is incompatible with > > > alloc_tag indexing. > > > > You are asking users to workaround implementation issue by configuration > > which sounds like a really bad idea. Why cannot you make the fallback > > automatic? > > Automatic fallback is possible during boot, when we decide whether to > enable page extensions or not. So, if during boot we decide to disable > page extensions and use page flags, we can't go back and re-enable > page extensions after boot is complete. Since there is a possibility > that we run out of page flags at runtime when we load a new module, > this leaves this case when we can't reference the module tags and we > can't fall back to page extensions, so we have to disable memory > profiling. Right, I do understand (I guess) the challenge. I am just arguing that it makes really no sense to tell user to recompile the kernel with a CONFIG_FOO to workaround this limitation. Please note that many users of this feature will simply use a precompiled (e.g. distribution) kernels. Once you force somebody to recompile with CONFIG_PGALLOC_TAG_USE_PAGEFLAGS=n they are not going back to a more memory optimal implementation. Just my 2cents -- Michal Hocko SUSE Labs