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 0A12FD15DBB for ; Mon, 21 Oct 2024 16:33:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 851046B0085; Mon, 21 Oct 2024 12:33:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E49B6B0088; Mon, 21 Oct 2024 12:33:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67AB56B0089; Mon, 21 Oct 2024 12:33:05 -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 4546D6B0085 for ; Mon, 21 Oct 2024 12:33:05 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 311AC41A2C for ; Mon, 21 Oct 2024 16:32:56 +0000 (UTC) X-FDA: 82698153762.29.324BC30 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf11.hostedemail.com (Postfix) with ESMTP id 2638B40015 for ; Mon, 21 Oct 2024 16:32:44 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Tw96lDfT; spf=pass (imf11.hostedemail.com: domain of surenb@google.com designates 209.85.160.172 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=1729528232; 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=KhDaWTmJM6nlwXBFOjmpIqQOnLI9apyaahvjApCJ+z0=; b=UiNwNsZl8xGvWeQbda/Achj0ygd3rGweGe/UqCsrufFCG3TS/+O3TOz6/B83sP/+MAF+/2 SrTgvAa9On/OfOUT4PxbFg5HPkEBy855OH5B8hh2HjekVL1tSn2iVYL5UxPMFDumPJJpqx 7JTZH8B+1n+CYcDKvCAq0pfMHf+fUCs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729528232; a=rsa-sha256; cv=none; b=U3/95cNNrK+OmYZ86kpHex1AnVmwbcolZ2m0LOY20WEzRYh7K1tPVOr0EvMeUiD4wa3yHc FEcBTeHYDG7u1YlHJrubqd35njF2/IFzbpp7tIE5vkEn2H3IjdbkNUURMgWs+scxz2YFY+ Qg2qlMiCyR6PxH8uWt3WIXOX6gGYB+w= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Tw96lDfT; spf=pass (imf11.hostedemail.com: domain of surenb@google.com designates 209.85.160.172 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-460b295b9eeso341261cf.1 for ; Mon, 21 Oct 2024 09:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1729528382; x=1730133182; 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=KhDaWTmJM6nlwXBFOjmpIqQOnLI9apyaahvjApCJ+z0=; b=Tw96lDfT1PVDRvkRqLMKqEHuMNej54nBVgA7S2jCMZF7D3BQXyazKVssow9HEHkY0D OVRaEi9dlKng0yWDIsNhAP1RYC7Ln11mEiRAgQ7ZcKLjvjlKHsu8FGTncvfPJ8m2D9hY dDk9BF/6vIQn2mFA1BHca5x0FlNc6Yff/WyQ2JAFoEjGnosAoH4pnjRagIg4MFgeo/5W mwqErSzWEzcPX3IC5AxH0JTY0gmqF+5DJBkQpQL7fPwntJ8S2EiSfafwoTqb2242J3m4 gQNs85D1p8PhadZfJg8JGECD3r0201zQx8/O/uUnZqJz48Ae7hCfIpsitqF2+OLFP0su gprA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729528382; x=1730133182; 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=KhDaWTmJM6nlwXBFOjmpIqQOnLI9apyaahvjApCJ+z0=; b=tAR3gvO1QTc7FSW25BmXX2Wih5dIe+t2K+TcwcE3SA4Oii/no42ZMLRqsGK1l+t3At AtWImfqGTxkF7onZ7V3UCg+nyYwYFJ15iz+SrrddfgvY/e8iUydPGtJziQyjhOYRMw7T Fd/4w7Z/iaY0hOWNMF/PeaUebi+dvMyo6G3FwcDpBr2XIgIVlC6vdokq5hdItPwC1Ks3 SLa7eWJ+fJWWjWIMADik0vWYP60E7JV/CqoaeRq/O384cOuMm8v5uYB0SEfBedGIrg7J ORs6R2PwSvDzJ++ft3Hm8mI20xrjMagUmqHRiQg0sQUvy5RAzzNTgkgwUDcMeU8ZadQN 5lIg== X-Forwarded-Encrypted: i=1; AJvYcCUca1srkDZSUb5RwrpKpvz5sp8oObLnmUSWYaZhsXvt1p/usvw3jCIUKqnux8WWb3AXeQHkBFzDgw==@kvack.org X-Gm-Message-State: AOJu0YzDTaCsleoFpMhjoG87WOL5YSxrjdCKx4YFrGkOhOwHmBRKhmOA RiCDxbI3+Z9cRKj6QVHBN50nBCuHju5bKOlsXYVeTxV40LjHO12+o+02TaVw3jkJ5fL2sQnVH8s 6JEmjoFVhxWnuc+OiLx7NNo88pNuEcsB0eQgh X-Google-Smtp-Source: AGHT+IEQJ7/dyf+59nB7w/ddzz12Ku666cGjBPoxf5tsDd/h9NHtih3CUtvHgU9dx314ldpzIPEbnG3QzndRB2BJVaA= X-Received: by 2002:a05:622a:1a18:b0:460:77ac:8773 with SMTP id d75a77b69052e-460bc5cf9c1mr4982821cf.26.1729528381808; Mon, 21 Oct 2024 09:33:01 -0700 (PDT) MIME-Version: 1.0 References: <62a7eb3f-fb27-43f4-8365-0fa0456c2f01@redhat.com> In-Reply-To: From: Suren Baghdasaryan Date: Mon, 21 Oct 2024 09:32:50 -0700 Message-ID: Subject: Re: [PATCH v3 5/5] alloc_tag: config to store page allocation tag refs in page flags To: Michal Hocko 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 7k8j6u6ha54uces9539813bb8jfj8ipd X-Rspamd-Queue-Id: 2638B40015 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1729528364-687076 X-HE-Meta: U2FsdGVkX1+qmnBLr99ADToakFm2vOeHRbWG160HpxrKKRJoNR+jPs3Vthf/aoS43UEORGO6GaK4fuv4bPl8w573glnIhgFlAei8GlXI8Tc0FcI9Mo4QGcSi2LPHsRkO4kuB6YGUFtYoiKERQ0nL3IT+lSJ6O+NIsdqtWN1Q9EV7Mx9g2W5lbF7W2J16cZTabdfGgSd2dgd4iKBZuX0o8Nal5rJzbil2xVd/gEI7ezegiIEEjuTdCkHzwiFgpPs+Jz6W3G/9j0No8Tj3gjlnneCnYhDksLh5YZCfDMS0krf7yRapcWG6zLmtGz+JHKKIWd1AyA3JoMbPqrxa+cO8lrYKcYKDjoJWViUaGQbijw+OM9z4Y/eC9A+KjtEvy0RktiZ/o/U9N6LAzONfJ6p1X16iXaVFsqa3vosOJXRXDJHYS8xK1lqrLHxoOUzdlcA5Fz8zMGsO+K745FO+L8F66Y14zyexm1Wq9VQ2dz+QubKfc6cfIK5PhtZPyRE7w03zDvPSv1zARE3fgtnYoiaGGn47q3dBljWOepf4myg1PPby8GuiSN27YxrVWItCdoQhrg5E8lBlDu1D5nNnsFnvzumKmb5u09+z2TgekYPxT7oW0NHB0nk6O2IHARU0Jcx9UhXdBXFl0wk0F47me4oweX1A9YmcTGY7OB8crt1g+cLsGJYA/mNnSI/Pq+nqp29iu6J4yvsGuUWgEPGc95n1cTGg08HmcYpX6wLL5Ja6AV0VF2KpDrExeGvi6GzOWOLFRDMQu5V23cWPa1xxJnXSSMk7sihhPilY2z8zbxlGE6GTV2cn1i97nIVUntxek6JQZwdBjRhcIZ5qNl0UZ6R4xho70fCWxxt55ketUKgcp5R1dB8uZiglOQt/BBal9F0/VLAJizpB0awF+NjPGuutCrrBEU3kVz/rdpD+2xj3kskgrq+LG/3Py6OFFF5ftzkI0Y2otBW9FTfQSPFOODZ DK3XDesn o0AdDN7gYW1OtW70IlfJ69w1W2HzlrRjcHE3Ogoyj33YE8dzo2UbuU/2b2UFc2zxMR8YPIpvVtoC8HvzDwLzbuwpo8/sJ6i72hGNXBEzznJP+6AdBDYPpuZksTnCY+vSa+48QGMHoGiZmEe1Lz+dF3nPRmJQlnimrJS9NOvA1Jkj3OLu5xP1GOAmPigR3KoaQw6Bpwha+4j00B5NutoGibBR3XIC3E2ZbXYc+IvU3Z3ztutuNsBqf40c8CExb/glI+MmG7cG1kMS/KMgeH9n6N5BRGSsRHqHsA1kGfdqOhgXEuJ8= 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 21, 2024 at 9:23=E2=80=AFAM Michal Hocko wrot= e: > > On Mon 21-10-24 09:16:14, Suren Baghdasaryan wrote: > > On Mon, Oct 21, 2024 at 8:57=E2=80=AFAM Michal Hocko = wrote: > > > > > > On Mon 21-10-24 08:41:00, Suren Baghdasaryan wrote: > > > > On Mon, Oct 21, 2024 at 8:34=E2=80=AFAM Michal Hocko wrote: > > > > > > > > > > On Mon 21-10-24 08:05:16, Suren Baghdasaryan wrote: > > > > > [...] > > > > > > Yeah, I thought about adding new values to "mem_profiling" but = it's a > > > > > > bit complicated. Today it's a tristate: > > > > > > > > > > > > mem_profiling=3D0|1|never > > > > > > > > > > > > 0/1 means we disable/enable memory profiling by default but the= user > > > > > > can enable it at runtime using a sysctl. This means that we ena= ble > > > > > > page_ext at boot even when it's set to 0. > > > > > > "never" means we do not enable page_ext, memory profiling is di= sabled > > > > > > and sysctl to enable it will not be exposed. Used when a distri= bution > > > > > > has CONFIG_MEM_ALLOC_PROFILING=3Dy but the user does not use it= and does > > > > > > not want to waste memory on enabling page_ext. > > > > > > > > > > > > I can add another option like "pgflags" but then it also needs = to > > > > > > specify whether we should enable or disable profiling by defaul= t > > > > > > (similar to 0|1 for page_ext mode). IOW we will need to encode = also > > > > > > the default state we want. Something like this: > > > > > > > > > > > > mem_profiling=3D0|1|never|pgflags_on|pgflags_off > > > > > > > > > > > > Would this be acceptable? > > > > > > > > > > Isn't this overcomplicating it? Why cannot you simply go with > > > > > mem_profiling=3D{0|never|1}[,$YOUR_OPTIONS] > > > > > > > > > > While $YOUR_OPTIONS could be compress,fallback,ponies and it woul= d apply > > > > > or just be ignored if that is not applicable. > > > > > > > > Oh, you mean having 2 parts in the parameter with supported options= being: > > > > > > > > mem_profiling=3Dnever > > > > mem_profiling=3D0 > > > > mem_profiling=3D1 > > > > mem_profiling=3D0,pgflags > > > > mem_profiling=3D1,pgflags > > > > > > > > Did I understand correctly? If so then yes, this should work. > > > > > > yes. I would just not call it pgflags because that just doesn't reall= y > > > tell what the option is to anybody but kernel developers. You could a= lso > > > have an option to override the default (disable profiling) failure st= rategy. > > > > Ok, how about "compressed" instead? Like this: > > > > mem_profiling=3D0,compressed > > Sounds good to me. And just to repeat, I do not really care about > specific name but let's just stay away from something as specific as > page flags because that is really not helping to understand the purpose > but rather the underlying mechanism which is not telling much to most > users outside of kernel developers. Understood. Ok, I'll start changing my patchset to incorporate this feedback and will post the new version this week. Thanks for the input everyone! > > -- > Michal Hocko > SUSE Labs