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 0D509D42BBE for ; Tue, 12 Nov 2024 18:15:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 807396B00D0; Tue, 12 Nov 2024 13:15:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B6A96B00D1; Tue, 12 Nov 2024 13:15:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 658046B00ED; Tue, 12 Nov 2024 13:15:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 440816B00D0 for ; Tue, 12 Nov 2024 13:15:04 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E50DE404D9 for ; Tue, 12 Nov 2024 18:15:03 +0000 (UTC) X-FDA: 82778243772.11.2CEEB4C Received: from out-184.mta1.migadu.com (out-184.mta1.migadu.com [95.215.58.184]) by imf19.hostedemail.com (Postfix) with ESMTP id EAFB81A0019 for ; Tue, 12 Nov 2024 18:14:08 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=msudGWks; spf=pass (imf19.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.184 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731435214; 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=d8/ZE0KHOIIicHT1JQ4FzqCuQ19CG0YU7NmLKz0bP0A=; b=OrC+PwaaSeh5Pv5Jr2QeWh5ejs2xH3WXRpr30AKmK8cOeNK7umfmWZhUjDpnEu5bmNgerY sfNYimhNC8eXvwtE+o2fvGIxe1SxunalBbMK1HVO+2Njf4qnfDJhfNiVBqt0gPaNUlTnd4 +i7yLWvHcMGSMv1figpTls0q5FrC2Co= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731435214; a=rsa-sha256; cv=none; b=TxUSE/frHsZfWranVNqT/IFXjM0jAEvIAe8NbCjnipPJUItJ+/KsIE2VTzdM8vC1VG43tu p/z79aHyG/UOc6MuCyPD+iCqFLP97XAUsVEVlOVSK/q+BewlyYtXgfA8DLIvBqC/VwCz6l Qx9afwxpmtnLMEF8KretTI/Kj4kJA4M= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=msudGWks; spf=pass (imf19.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.184 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Tue, 12 Nov 2024 13:14:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1731435299; 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=d8/ZE0KHOIIicHT1JQ4FzqCuQ19CG0YU7NmLKz0bP0A=; b=msudGWksSYzgnmjp5P6ize+I22JN2SJ1DWQ82pNx/LfS7g9i5BvGuPdQEvoOJmOmtYZqoL 6yeOEqHDRQzRB+qObdacgNHQyc9NIQpUMaYRz4G9yvfkmiL1aZocDUAi0ZiaBMuT9DBLPm xS7ylFT72XbC+dJfVZqn+VVBCdAduyg= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Hao Ge Cc: Suren Baghdasaryan , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Hao Ge Subject: Re: [PATCH] lib/alloc_tag: Remove the sysctl configuration to prevent users from disabling it at runtime Message-ID: References: <20241108075004.131911-1-hao.ge@linux.dev> <71703c20-8311-ce3f-fbed-27d2ec3a2c82@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <71703c20-8311-ce3f-fbed-27d2ec3a2c82@linux.dev> X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam10 X-Stat-Signature: kytdar98hemjesrka69fkniz11p3ftdp X-Rspamd-Queue-Id: EAFB81A0019 X-Rspam-User: X-HE-Tag: 1731435248-956154 X-HE-Meta: U2FsdGVkX18D4MlfNS97D2YKfq52UPVuiBlVybqEmI/mtXbWWramu43ZPznZzqta8fW5VSHy34t3v73ek8XCjMiqG6HjyPqEf8G146CDGRxfFPIFtJf4rcRzyPxvhOTzLcG5Gv890afRHOtrYMfcwpiMaPkO9yi4twQ2222N65LIhv5O8GdBfhKXzuAz4FAJt2+pyWUbKy0BMxBYZ7mMmsE0lDjO95G9P3abmknHChJPILFiXK7yZX7qCITH67rgtPElpfIXxQSv2zNj1eirg3IwWVLC4wBdqW4apArvlYrkL8D9Gtzu7X8f1zmk57r79lc/YsNMmPCc+NTXPHQNoGgoj70opd30yZXRGFYJTuYmy4ci6iypr5EYgO9f9MdbpVDf9BSAOypmcd2osFzJAgm+8qsKTZ6i2Rxiao3o2mHlqSmLhtYjtlUte3JmHdeFIQfHemeTzsLAnjS7Kw/a8T/RUpgWfmPEHgBE7DDZTkAxGz9WNZNPEp1UMoWsPe5CAag0GS6BnWxRCMR1QWoCnBwIxgHQNrxrucm41dAbrCKL+NR+cMTdsapaQLrH2c605e6/+3h/44pffrbB3eVdmd0jmx/wqAeFEThNtibx20QTzWds8U1F5+a/U+UOO5kvYatAkupTjvDHI57Ab1FH6EX0o4rfYFEMOnn2azna1ikFdByfi0FFC1/yWm6vjaEDnUWUqiM97rE9UhxjZAmEqSt4wsH4W/9lr1MjkWNsssYsfp7YZQ/9OayDV8wNF0H1YzMPq6Hmt3GnbtgadZqxwQ6BsXtESSbTftJxTEdItd4wFqtuGT+R4GqV+H8et4p4Wkgxxp2YWsvdY3etVNKGDcyBRbvYcOVAkOcTX0HyBvEh9dE4a3Sks4LzHA+ACiiKL/wd5mB6DX0Fllg/7BVAT+Ohe+zWB5JukGWsvtU6fW4w085QSgrJCofpKCQBoQjfZ3zH5xiHPX0yjIgyyfA f65frKNG CAUn/86lkupnb0x3PrZCaHpLWwbsnR8smN1ZVHCOd2dwbkB5clRMAnso9KMeU8/fd+p0nIg53+84F+CLhH13K0xVQ2AkbWHGklLLv9wLlqGbnw69rq0IFoGzIjofLmlZRCrdj6Xzzrbtgze9BgmnGCSyL7hFTx/uR8d1eHoFWoR6ackfbYe0jkgFKt7Ur7VTsVUmXeQK6iLCZh0+Oxdy/0WoPMA== 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 Tue, Nov 12, 2024 at 11:30:39AM +0800, Hao Ge wrote: > Hi Suren > > > Firstly, please forgive me for my improper wording in the commit message. > > After sending it, I realized that I should have used "suggestion" instead of > "decided". > > Secondly, please forgive me for taking a few days to respond. I've been > quite busy these days. > > > Let's continue to discuss this issue. > > > On 11/9/24 02:16, Suren Baghdasaryan wrote: > > On Thu, Nov 7, 2024 at 11:50 PM Hao Ge wrote: > > > From: Hao Ge > > > > > > After much consideration,I have decided to remove > > > the "mem_profiling" sysctl interface to prevent > > > users from dynamically enabling or disabling the > > > MEMORY ALLOCATION PROFILING feature at runtime. > > > > > > I have taken the following actions: I set > > > CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT=y to > > > enable memory allocation profiling by default, > > > and then made adjustments to mem_profiling dynamically > > > during runtime. > > > > > > When I ran the OOM test program, I obtained useful > > > information that was indeed very helpful for debugging. > > > > > > [ 1023.065402] Memory allocations: > > > [ 1023.065407] 12.8 GiB 6546 mm/huge_memory.c:1328 func:do_huge_pmd_anonymous_page > > > [ 1023.065412] 873 MiB 229985 arch/arm64/mm/fault.c:986 func:vma_alloc_zeroed_movable_folio > > > [ 1023.065415] 187 MiB 29732 mm/slub.c:2412 func:alloc_slab_page > > > [ 1023.065418] 99.8 MiB 25560 mm/memory.c:1065 func:folio_prealloc > > > [ 1023.065421] 47.2 MiB 3189 mm/readahead.c:434 func:ra_alloc_folio > > > [ 1023.065424] 30.0 MiB 15 mm/khugepaged.c:1072 func:alloc_charge_folio > > > [ 1023.065428] 28.6 MiB 514 mm/compaction.c:1880 func:compaction_alloc > > > [ 1023.065430] 25.8 MiB 6592 mm/page_ext.c:271 func:alloc_page_ext > > > [ 1023.065433] 25.6 MiB 6546 mm/huge_memory.c:1161 func:__do_huge_pmd_anonymous_page > > > [ 1023.065436] 23.5 MiB 6017 mm/shmem.c:1771 func:shmem_alloc_folio > > > > > > After running echo 0 > /proc/sys/vm/mem_profiling > > > and then executing the same test program, > > > I obtained the following results > > > > > > [ 1156.509699] Memory allocations: > > > [ 1156.509703] 187 MiB 29645 mm/slub.c:2412 func:alloc_slab_page > > > [ 1156.509707] 142 MiB 9357 mm/readahead.c:434 func:ra_alloc_folio > > > [ 1156.509710] 136 MiB 41325 arch/arm64/mm/fault.c:986 func:vma_alloc_zeroed_movable_folio > > > [ 1156.509713] 99.7 MiB 25531 mm/memory.c:1065 func:folio_prealloc > > > [ 1156.509716] 56.0 MiB 28 mm/huge_memory.c:1328 func:do_huge_pmd_anonymous_page > > > [ 1156.509719] 30.0 MiB 15 mm/khugepaged.c:1072 func:alloc_charge_folio > > > [ 1156.509723] 28.6 MiB 514 mm/compaction.c:1880 func:compaction_alloc > > > [ 1156.509725] 26.3 MiB 7460 mm/readahead.c:264 func:page_cache_ra_unbounded > > > [ 1156.509728] 25.8 MiB 6592 mm/page_ext.c:271 func:alloc_page_ext > > > [ 1156.509730] 23.5 MiB 6016 mm/shmem.c:1771 func:shmem_alloc_folio > > > > > > Because mem_profiling was disabled by executing > > > echo 0 > /proc/sys/vm/mem_profiling,we are unable to > > > record memory allocation information after the disablement. > > Naturally you are unable to track the allocations after disabling it. > > You disabled it as root, so I assume you know what you are doing. > > > > > These output logs can mislead users. And similarly, the same > > > applies to alloc_info. > > I would understand if you made /proc/allocinfo empty after disabling > > it to avoid confusing the user, but ripping out the ability to > > enable/disable profiling at runtime does not make sense to me. Once > > you collect required data, disabling profiling gets you back the > > performance that you pay for it. There are usecases when a program on > > a remote device periodically enables profiling for some time, records > > the difference in allocations and then disables it. Your change breaks > > such users. > > > Actually, my original intention was also to make /proc/allocinfo empty when > disabling it, > > but I considered the following scenario: after we disable it and clear > /proc/allocinfo, > > we then start a memory-intensive application, > > such as our OOM (Out-Of-Memory) test program. > > If we later enable it again, the issue described in my commit message would > still arise. > > Perhaps we need to further consider how to handle this situation. Why would you do such a thing? We put a lot of effort into making memory allocation profiling cheap enough to leave on, and I haven't seen a single complaint about performance overhead.