From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-180.mta0.migadu.com (out-180.mta0.migadu.com [91.218.175.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 210D440B0FB for ; Tue, 4 Aug 2026 04:14:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785816843; cv=none; b=a91vNNmvX4zyW+QBiPSW3llg5tFw/1vIzy6Sy66XGCAL9rCd3Q/UtFhqTP5HiyJ3UYOqu+iwusJPrf/xAlwiaE6ONViEWCBprEJYi83OC+eB9XLybiECUJtTqTjSuFjoDJc9j4qmfOgBwUXz1kajgxjPP1p4W1iwN+ev5dmRl+A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785816843; c=relaxed/simple; bh=jRRp00rM3Axnjl4dN9jVkxYEWwggQqsN9lpDkCzRj9g=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=W79KYLXY/O5KVtVCBnilbaEck1vnjzjOKUe4LHj8JGV9gS8mVSDIN0Fm6dZJF8QefI41tPksc8lyWELdE8QGRSuChj4kbSLl4HcrNnLNmZVwKma9unIFbrKvSUAgfybrJGMuy25u3U4GlVIP5vdm4nUmgYeUAuRBGpo7BslpbVs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=kzDwUarm; arc=none smtp.client-ip=91.218.175.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="kzDwUarm" Message-ID: <7e71f6d4-7bc9-449c-a122-49f0e8397150@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1785813487; h=from:from: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; bh=2TYt7/NXCNfbzYI+3NGISTe3bg1kbYgcSnqzrzdlGnk=; b=kzDwUarmgBcrC001qK2OiyEX3bI9pMpBTJYaF8KZYpwVs791J9xF9rP4lCDnjQDNllPuJb itVJ5XQEOEIFCWnxBLh6cA3O9IUxUTcHBhHr7QCeUnEmmAg8aQrSvtWwFWHkRwmvJ+8K5f 0R07ZWmLYHS06GnhUrFg3jLhOexpnrs= Date: Tue, 4 Aug 2026 11:17:58 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v3] alloc_tag: expose profiling and compression states X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Hao Ge To: Abhishek Bapat Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Suren Baghdasaryan , Andrew Morton References: <0b95c0df-8cf6-4ad9-9552-d7c4a657a25c@linux.dev> Content-Language: en-US In-Reply-To: <0b95c0df-8cf6-4ad9-9552-d7c4a657a25c@linux.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 2026/8/4 10:15, Hao Ge wrote: > Hi Abhishek > > > Subject says "profiling and compression states", but this > > patch only adds the compression sysctl. The profiling state was > > already exposed via mem_profiling and is untouched here. > > I think we should make this more precise, like: > > alloc_tag: expose boot-time compression configuration > > > On 2026/8/4 05:54, Abhishek Bapat wrote: >> Currently, userspace has limited visibility into the exact active >> runtime state of memory allocation profiling and its page extension >> compression ('sysctl.vm.mem_profiling={0|1|never}[,compressed]'). > > > Profiling state is already readable via mem_profiling. The gap is > > only compression. Also, as we discussed, this sysctl reports > > what the user requested at boot rather than the actual runtime state. > > >> While reading the sysctl provides basic on/off status, it is currently >> impossible for userspace to natively determine whether page-tag >> compression was successfully enabled without scraping dmesg boot logs. >> >> Resolve this ambiguity by exposing the active compression state by >> adding a new read-only sysctl `vm.mem_profiling_compressed` to output >> the >> state. >> >> v3 change: >> - Added documentation about the behaviour details of the new sysctl. >> >> v2 change: >> - Moved from displaying the state in /proc/allocinfo to a new read-only >> sysctl. > > > As this is a standalone patch, please put the v2/v3 changelog below > the --- line > > instead of inside the commit message. > > > Thanks > > Best Regards > > Hao > > >> Signed-off-by: Abhishek Bapat >> --- >>   Documentation/mm/allocation-profiling.rst | 13 +++++++++++++ >>   mm/alloc_tag.c                            |  6 ++++++ >>   2 files changed, 19 insertions(+) >> >> diff --git a/Documentation/mm/allocation-profiling.rst >> b/Documentation/mm/allocation-profiling.rst >> index c3a28467955f..3ad1e9aacb9a 100644 >> --- a/Documentation/mm/allocation-profiling.rst >> +++ b/Documentation/mm/allocation-profiling.rst >> @@ -43,6 +43,19 @@ sysctl: >>     warnings produced by allocations made while profiling is disabled >> and freed >>     when it's enabled. >>   +  /proc/sys/vm/mem_profiling_compressed >> + >> +  1: Page extension compression is enabled. >> + >> +  0: Page extension compression is disabled. >> + >> +  This control is read-only and reflects the compression status >> initialized at boot. >> +  Note that, unlike `mem_profiling`, which represents the current >> state of profiling, >> +  `mem_profiling_compressed` represents the state configured at boot >> time. Sorry, I forgot to mention this earlier. I wonder if we could remove this section: >> Turning off >> +  profiling at runtime will implicitly make this sysctl effectively >> dormant. However, if >> +  profiling is toggled off and then toggled on again, it will resume >> with compression >> +  still enabled as long as the value of `mem_profiling_compressed` >> is 1. mem_profiling_compressed only selects the tag storage format (page flags vs page_ext). mem_profiling controls whether allocations are tagged at runtime. The two are independent: toggling mem_profiling on/off has no effect on compression. Only shutdown_mem_profiling() tears it down, but by then the entire allocation profiling subsystem is disabled anyway. There is no resume path. >> + >>   Runtime info: >>     /proc/allocinfo >>   diff --git a/mm/alloc_tag.c b/mm/alloc_tag.c >> index 52aece27b00e..877068241f06 100644 >> --- a/mm/alloc_tag.c >> +++ b/mm/alloc_tag.c >> @@ -1303,6 +1303,12 @@ static const struct ctl_table >> memory_allocation_profiling_sysctls[] = { >>           .mode        = 0644, >>           .proc_handler    = proc_mem_profiling_handler, >>       }, >> +    { >> +        .procname    = "mem_profiling_compressed", >> +        .data        = &mem_profiling_compressed, >> +        .mode        = 0444, >> +        .proc_handler    = proc_do_static_key, >> +    }, >>   }; >>     static void __init sysctl_init(void) >> >> base-commit: 94f9b3980dd446b56acf1dfed649e9b32a9f3813