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 7EEECC369CA for ; Thu, 17 Apr 2025 18:38:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 672026B00FC; Thu, 17 Apr 2025 14:38:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 622796B00FB; Thu, 17 Apr 2025 14:38:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 513026B00FC; Thu, 17 Apr 2025 14:38:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 34E466B00FA for ; Thu, 17 Apr 2025 14:38:25 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 7E908B8DFA for ; Thu, 17 Apr 2025 18:38:25 +0000 (UTC) X-FDA: 83344396170.29.94B08BD Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by imf30.hostedemail.com (Postfix) with ESMTP id 9A45880005 for ; Thu, 17 Apr 2025 18:38:23 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=jy+kwEGc; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of surenb@google.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744915103; a=rsa-sha256; cv=none; b=Gp5r8j58MaHE+aNzRMiMncJDWUdQptB7vGhh6sviSkseu8gVKzScUjDGRRd+4aLvpEmpDv e9HVJpiqfJ8okCnyU2edayPAsKZfDJz3l2aUAE/oN1KovD2YXXteKvLkl89lKTk6CrwovV a0qSyygeUcJca42bMAwr3Lk3qxxBbJ4= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=jy+kwEGc; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of surenb@google.com designates 209.85.160.181 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=1744915103; 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=Bza0S7y0BSrOZcrZPdnoUbcyu9+YRt1jcvBqpA00DmQ=; b=12vGAbp6FryobIkIEKYSXHB54XGHcltCVwZT4gp3dDQSi5PM8AIVnuB0dqYqPGN42sr414 QbIbdWJ7lnkSM8aBEN279Bv/6+WzO6zV5hIKkFmSioByynpF5RB773w0foRa/8tu5aGxsg 9pn9jqOLKjWCkMREqDlxUum6vbk0I7o= Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-47681dba807so32171cf.1 for ; Thu, 17 Apr 2025 11:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1744915103; x=1745519903; 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=Bza0S7y0BSrOZcrZPdnoUbcyu9+YRt1jcvBqpA00DmQ=; b=jy+kwEGcFjJy3emXc+cpxOE+mCC8CbwJKCJiDpZVz9nChvtlRx/0ZTsgd9Th1UD8KJ FyD4EOWqviH+vdG3H1fMik7ZGxu5OBmP4qnMb39ASINDbMIFlq4uqGvPwEUSpsAefnUK DZPkJnnsPtMNxj1oJ5ZrVYhaZZnCAfuMUFr2S1QHYxkeX5pAIBCHWDFFuTsu5qi2EQ45 jtP5SpXrBN1t+ruq6ZqH0ZW0cpLACwgYuXhESGrLZDhlWITPVJV/wFA5rASdvhAuZo+q 2memewixUMWktd0SENRwoy4k0KXHLu1KdE0+AyT+IXSubMZ1+T1LIRy8Q9IzQ5CFeSZu LXyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744915103; x=1745519903; 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=Bza0S7y0BSrOZcrZPdnoUbcyu9+YRt1jcvBqpA00DmQ=; b=dElon3mx22S9SRXAu+0yOzcgPeFgESw2LswNVxUarC1iGqOVcXt1QFbdU6CL9p10lT w9al34vQlsZOv9ZM1tMdYfTp9q9cth+X7yPpLIkIrxQT+T5aZDCxSKZXHxDL8InnZT36 Aa34WcV1Cwl/YoCpCdW/U8uyo9zI4WWcpTJuWsJPGHG9o65ZCLXRMLpw2QWgZ/M0lgN8 FOKDwQQcHAh8gXfbxXmpRSmn2uucbZYJuWzdYtY0vX2ltZZpeqzKJHIxI5oq/py1AIOd 8UAgbDVxZiiv8P4NfkVDsXpw/rJ+ZdrYbMwpOJS8Hi+TQ02UmUXUxrFIoUgNnZwPT/57 wcUA== X-Forwarded-Encrypted: i=1; AJvYcCW2F9m8ANOaM8p9Za5DbqvSKCjl8NE9w2SQSwxx0bM2mYEDh7h34r9FPofrLZ0uw5z8PGDlnyAODQ==@kvack.org X-Gm-Message-State: AOJu0Yyljc7GYW/qxem7T8ymQGVgh+MAa+FlMQapez6o2uDloQFl32Mk LUNsHeIhdAN/q5/3FVNdut5tpxsk+/lbxVmOsqLN03eKINDdhNzZYRXSXl8dMOe/pD54Bd59LG/ 0GTVOEaJq9Pe3cjYA9sjJTpXBIX2UMITFuIFLbCSbKkk3KIKXMYDbIFI= X-Gm-Gg: ASbGncv69EOh9myXX7OhbGv69cMzg3GI8JAO3dvtL7VhHxi/rb7/A5FoeBaP4ekd+HQ UDSICroPzECW2hSXniGdIqjbZeWZbJpns4P+39w1OQulm5xYMPocUczyBJUayedl9O6wB1ikEYb 24hJStOCzBJO//vQQSuhQVM86DTPQN0fD4WKGfLHRUveZ7z7Yekscp X-Google-Smtp-Source: AGHT+IHPnBHaTnH4LH3+4icCSqdkLnMYV5wERvYGA8h5jD/C6G9mBEm5V+Q6IeuGnI7YYsrtpxa55AmNXnsj9m62eso= X-Received: by 2002:a05:622a:1486:b0:467:8416:d99e with SMTP id d75a77b69052e-47aeb502cb2mr304241cf.21.1744915102519; Thu, 17 Apr 2025 11:38:22 -0700 (PDT) MIME-Version: 1.0 References: <20250416180653.3438158-1-usamaarif642@gmail.com> <72pac6pkjebt6xo7engiuuu7r3zr7fu6fh6bj77f22m7gslxgr@3gjawofplas2> <25ac1d9c-c7e4-4dcf-b297-254fa51c6f2a@gmail.com> <33632210-6de3-445b-8f9c-d0fbcf3deab2@gmail.com> In-Reply-To: <33632210-6de3-445b-8f9c-d0fbcf3deab2@gmail.com> From: Suren Baghdasaryan Date: Thu, 17 Apr 2025 11:38:11 -0700 X-Gm-Features: ATxdqUFS3lRu_At297sjMidDhBkDhQYSgQMk39ymxl8qM8ITyYvaVFMBMGhJouA Message-ID: Subject: Re: [PATCH] alloc_tag: introduce Kconfig option for default compressed profiling To: Usama Arif Cc: Shakeel Butt , Andrew Morton , linux-mm@kvack.org, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 9A45880005 X-Stat-Signature: ieqe85898nb6h46859okme4x1gpu8isj X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1744915103-793041 X-HE-Meta: U2FsdGVkX1+Hzh/4BxJCFOXUH6Ghligi2Z31HbcMnd9etAMiSdn9T1dx4uUuN4ELSJDsLe0vsvabb9Hpzuzpeva/zeWve1spWTKM+OaG0QG11bKYwnUuRtV1mAi1jT6XZnxs9yrzWHNW5uEEakF9/v2KZy5iFLP+T1OsMZf4zkGJjSuzfZAu2MyLkDxUPOuGUUMxCgVzcFHbwqZTG8yrTfauIz4QUe9xhU7GJqDujgJwG+0dDryEc8FUm1kiHI31ORZKqEGP9WAMu3j2w1PLEcZX7LSuIBbqYj9tO23NYYOIK7CgR4iHBkYMXFg5m0MaiEgeNTiEdOI6rB0/C2C+CyYFZuY0w/wDE//EBG+zEKEZuW9BU1dW1oWMClosTpXBdU83qRydwntELf4pJKRY9IhrE5+EYuRDhqbVETUjgrWFtalL4X1XGiFtg5rSMhz0Ys+xQNw3pZAaTXxZjbU43xcHnvzMB5yoW/b5jarKAUjEdVkVXen6DLQngAxwDGD6nvckulDcraRimANn544f+4zLjbjujatjGXu0TSS5SZawbZP9Ir1jI/X1yntbTDF+r6u8z36WMDmJ3XCB/3QhleeJCPOQGW3lmFIucDGq0rbZmIZHq1pvYsWUzdig1QhLZP5hc2dM2+wN1jrQS7Nr6qgmdqVnF/fKS+X7gCcfJdVJupHN9VSiCEmkIQVgr3JIoDkQZMQYQPO94ShYOK1t6UUtLWEiRWOGmII7FTx2XzpvrxmbPhcykd0sxiS8gDnj0Q+T0rwI0PVAlniuiMBAuV6mJNjnd5gPYHO1Pu1HK59Qclce0BV4cGoBcR/8kQn0IXRRVm8M8BbpdtlAowKSprjROsqAu6sCKnt+RVJJkx3rja2Kv/zHrQDFjUQhBefCkp6IT5gJszyXkygHyzIlVC7ZZFJ/OE44ZXQ8afiBHoKvxvIOqF0HWonvbL7KbrfGOOT2xj+0UpkN6OKiaPM dP0uja8W vUn5oYPBhamSOdaLgKA5vrXZNTK0GQ3uj6EWuz7PbLUIhSNRawJcDiK/b6C27sQZnTFanUUFSXqSwG8+P4gaOZnZH5aLG2OxtKJmZrfqaOAtq9HyzvfnjhTAvKA8QEMJmWzF1DGKQxcWJH44ueo4ygRr+zjePKHajnMCbKDkYRYX7rBmfqEPDucvzF088kJz3+d8rQCdp7m6Br2iLqoNRkn+cp2p2V4q1Jq2aqCfknimIYA1GwmxLj4pVNRocGZ080lj72ZSV0wn43vU= 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 Thu, Apr 17, 2025 at 11:35=E2=80=AFAM Usama Arif wrote: > > > > On 17/04/2025 18:50, Usama Arif wrote: > > > > > > On 17/04/2025 17:00, Suren Baghdasaryan wrote: > >> On Thu, Apr 17, 2025 at 8:47=E2=80=AFAM Shakeel Butt wrote: > >>> > >>> On Wed, Apr 16, 2025 at 05:11:11PM -0700, Suren Baghdasaryan wrote: > >>>> On Wed, Apr 16, 2025 at 2:41=E2=80=AFPM Shakeel Butt wrote: > >>>>> > >>>>> On Wed, Apr 16, 2025 at 02:08:31PM -0700, Suren Baghdasaryan wrote: > >>>>>> On Wed, Apr 16, 2025 at 11:06=E2=80=AFAM Usama Arif wrote: > >>>>>>> > >>>>>>> With this Kconfig option enabled, the kernel stores allocation ta= g references > >>>>>>> in the page flags by default. > >>>>>>> > >>>>>>> There are 2 reasons to introduce this: > >>>>>>> - As mentioned in [1], compressed tags dont have system memory ov= erhead > >>>>>>> and much lower performance overhead. It would be preferrable to h= ave this as > >>>>>>> the default option, and to be able to switch it at compile time. = Another > >>>>>>> option is to just declare the static key as true by default? > >>>>>>> - As compressed option is the best one, it doesn't make sense to = have to > >>>>>>> change both defconfig and command line options to enable memory > >>>>>>> allocation profiling. Changing commandline across a large number = of services > >>>>>>> can result in signifcant work, which shouldn't be needed if the k= ernel > >>>>>>> defconfig needs to be changed anyways. > >>>>>> > >>>>>> The reason tag compression is not the default option is because it > >>>>>> works only if there are enough free bits in the page flags to stor= e a > >>>>>> tag index. If you configure it to use page flags and your build do= es > >>>>>> not have enough free bits, the profiling will be disabled (see > >>>>>> alloc_tag_sec_init()). > >>>>> > >>>>> Is it possible to fail the build in that case i.e. check the page f= lags > >>>>> availability at build time? > >>>> > >>>> The difficulty is finding out the number of allocation tags in the > >>>> kernel before it gets built. Maybe there is a way to add an addition= al > >>>> post-build stage to run that check. > >>> > >>> Yeah that would be good to have. > >>> > >>>> But even then making this option > >>>> default and causing build failures does not seem like a good idea to > >>>> me but maybe I'm being too cautious? > >>> > >>> Oh my question was orthogonal to the patch. Basically some users may > >>> want build time guarantee for this and they can enable such > >>> build-failing opt-in config/check. > >> > >> Yes, that would require the post-build step to check the number of > >> tags vs the number of available page flag bits. I'll add it to my TODO > >> list but it won't be at the top, sorry :) Volunteers to help with that > >> would be highly appreciated. > > > > Hi Suren, > > > > A question orthogonal to the patch, the defconfig entry is defined as b= elow: > > > > config MEM_ALLOC_PROFILING > > bool "Enable memory allocation profiling" > > default n > > depends on MMU > > depends on PROC_FS > > depends on !DEBUG_FORCE_WEAK_PER_CPU > > select CODE_TAGGING > > select PAGE_EXTENSION > > select SLAB_OBJ_EXT > > > > i.e. we select PAGE_EXTENSION even if we use compressed profiling and u= se page flags > > instead of page extension. Which means the 0.2% (8 bytes per struct pag= e) memory overhead > > will still exist even when we dont need it? > > > > Should we have some defconfig option (happy with any other way) that on= ly allows compressed > > profiling (otherwise nothing), so that we don't have the dependency on = page extension > > and thus not have the overhead if we only plan to use compressed profil= ing? > > > > Thanks > > > Johannes pointed out the .need function of page_alloc_tagging_ops, i.e. n= eed_page_alloc_tagging, > so page extensions wouldn't be enabled and hopefully there is no memory o= verhead when > mem_profiling_compressed is true. Let me know if my understanding is wron= g. > And sorry for the noise! Sorry for the delay. Meetings... Yep, Johannes is right, need_page_alloc_tagging() should disable that overh= ead.