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 D0947C433F5 for ; Sun, 22 May 2022 04:33:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C1968D000E; Sun, 22 May 2022 00:33:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 270C98D0003; Sun, 22 May 2022 00:33:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 15FEA8D000E; Sun, 22 May 2022 00:33:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 06A558D0003 for ; Sun, 22 May 2022 00:33:14 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id C384A80841 for ; Sun, 22 May 2022 04:33:13 +0000 (UTC) X-FDA: 79492109466.03.83496AF Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by imf07.hostedemail.com (Postfix) with ESMTP id 5185D4000F for ; Sun, 22 May 2022 04:33:03 +0000 (UTC) Received: by mail-lj1-f176.google.com with SMTP id s5so13635136ljd.10 for ; Sat, 21 May 2022 21:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openvz-org.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=yCD06XVtIkpJKoi9CQKW+gdhYqTSRbN4wl/ZDZ8BgNE=; b=H4dSE3eNOXcrAi0YFzxEGRbDqkQwiBUSDobhm/nnz5/BYQ9GaUceHMkXCr04+Aujmd MS7GKoOz/s6c4ZIXh2kptGnQq/3o28njqYqsUdgQBtBpIDGbdx40nOBovSiuTHmpf1ry IJELEEo9HcIWdegkF7jEGGeIWooZLtkkXKUxsglmYM2whoj0mP+RnbD9mPE0Lg7uemfc FY7Nql9+XP1ZZcdStJi8W+bHMYG8+d1fI8+B0epVIlex77FyeQcj7aEuNcaoGgLGbwy4 yLUPEYTDNwnASi7tXZBAW6iGzs4AJ9oWLbkB4hc35mFOOwhAg8LX8xu9PMWyUeIndE/+ ar9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=yCD06XVtIkpJKoi9CQKW+gdhYqTSRbN4wl/ZDZ8BgNE=; b=LdDE1bqY/twXWOmnnWfFtZvFAR9r4TuOlHCDheWaimrPUuJ3nJwP+g6DsnwkvFCOs0 qqL68sL7Gja+SFuPk8Roy8SxB8sOSwhP1MChS5on3w18f5J/p2lIsZbS7TrqKuaGU3V9 /GbriC+gIymAEyd2NSsDEIIhTyfBiwzq7zKvWT7aYacdfz5D695R031bk9blrcBlgC/O ujYGmpjzcAawzrDuy41xNR/bZmvWftKax25+ESzR0kyTndSs+G8c73/IjXRLQSUPZNya MZgKTidfSMgU9u07JctcCNFr/8v1C6HxNWaILxJfsEXp2S4HevLZQDwwTgKAn4nuvJBk 9YdQ== X-Gm-Message-State: AOAM530HoVDrYh2Q3jC8uKCcPTMSFmO+cC8Fm0RIevPPOJGbLTq5ecxG bmfRkjYN05uaW67pv5BBXcvijQ== X-Google-Smtp-Source: ABdhPJwhUWVVKZhh9D4AI5iySEbCseAEfI/eBYhvDo8aVT15ST8pKT/3uNA30wOs5jwQ2C/NSSUMLQ== X-Received: by 2002:a2e:9d09:0:b0:253:e189:5a44 with SMTP id t9-20020a2e9d09000000b00253e1895a44mr3587978lji.225.1653193990759; Sat, 21 May 2022 21:33:10 -0700 (PDT) Received: from [192.168.1.65] ([46.188.121.185]) by smtp.gmail.com with ESMTPSA id y3-20020a2e9d43000000b00253dde4720esm963470ljj.90.2022.05.21.21.33.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 21 May 2022 21:33:10 -0700 (PDT) Message-ID: <1621d82a-439d-0657-2b7e-5e90c42c2087@openvz.org> Date: Sun, 22 May 2022 07:33:08 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v4] tracing: add 'accounted' entry into output of allocation tracepoints Content-Language: en-US To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Andrew Morton , kernel@openvz.org, linux-kernel@vger.kernel.org, Steven Rostedt , Ingo Molnar , linux-mm@kvack.org, Shakeel Butt , Roman Gushchin , Vlastimil Babka , Matthew Wilcox , Joonsoo Kim , David Rientjes , Pekka Enberg , Christoph Lameter , Michal Hocko , Muchun Song References: <0c73ce5c-3625-6187-820e-1277e168b3bc@openvz.org> From: Vasily Averin In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 5185D4000F X-Stat-Signature: b7d5ymiaqq59r3pd9aw6yzt8515i7y88 Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=openvz-org.20210112.gappssmtp.com header.s=20210112 header.b=H4dSE3eN; dmarc=pass (policy=none) header.from=openvz.org; spf=pass (imf07.hostedemail.com: domain of vvs@openvz.org designates 209.85.208.176 as permitted sender) smtp.mailfrom=vvs@openvz.org X-Rspamd-Server: rspam04 X-HE-Tag: 1653193983-313167 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: On 5/22/22 06:51, Hyeonggon Yoo wrote: > On Sat, May 21, 2022 at 09:36:54PM +0300, Vasily Averin wrote: >> Slab caches marked with SLAB_ACCOUNT force accounting for every >> allocation from this cache even if __GFP_ACCOUNT flag is not passed. >> Unfortunately, at the moment this flag is not visible in ftrace output, >> and this makes it difficult to analyze the accounted allocations. >> >> This patch adds boolean "accounted" entry into trace output, >> and set it to 'true' for calls used __GFP_ACCOUNT flag and >> for allocations from caches marked with SLAB_ACCOUNT. >> >> Signed-off-by: Vasily Averin >> Acked-by: Shakeel Butt > > May I ask what information do you want to collect > using this patch? I analyze ftrace output to understand which allocations are accounted. When some userspace operation consume memory, it's important to account most part of memory (>2/3 of all) to avoid misuse inside memcg-limited contianers. Otherwise memcg-limited container can consume significant portion of host memory, trigger global OOM, wake up OOM-killer and kill random processes on host. If memory consumers are accounted, it leads to memcg-OOM only. Now kmem tracing output looks like this: kmem_cache_alloc: (getname_flags.part.0+0x2c) call_site=getname_flags.part.0+0x2c ptr=0xffff8fff022e9000 bytes_req=4096 bytes_alloc=4096 gfp_flags=GFP_KERNEL accounted=false kmalloc: (alloc_bprm+0x32) call_site=alloc_bprm+0x32 ptr=0xffff8fff2b408a00 bytes_req=416 bytes_alloc=512 gfp_flags=GFP_KERNEL|__GFP_ZERO accounted=false kmem_cache_alloc: (mm_alloc+0x16) call_site=mm_alloc+0x16 ptr=0xffff8fff0894d500 bytes_req=1048 bytes_alloc=1088 gfp_flags=GFP_KERNEL accounted=true mm_page_alloc: page=0xffffffffa4ab8d42 pfn=0x12ad72 order=1 migratetype=0 gfp_flags=GFP_USER|__GFP_ZERO|__GFP_ACCOUNT kmem_cache_alloc: (vm_area_alloc+0x1a) call_site=vm_area_alloc+0x1a ptr=0xffff8fff2af27000 bytes_req=200 bytes_alloc=200 gfp_flags=GFP_KERNEL accounted=true As you can see, without new field it is quite hard to understand, is last allocation accounted. This analyze helps me to identify most important allocations for given scenario and enable accounting for selected allocations. An example of this analyze you can found here: https://lore.kernel.org/all/d28233ee-bccb-7bc3-c2ec-461fd7f95e6a@openvz.org/ > I pointed it in another thread but I'm not sure > printing SLAB_* flags in these tracepoint is good :( I'm not sure I understand your arguments correctly. Could you please explain your position in more details? > If we decide to do that, it would be better to print > something like: > slab_flags=SLAB_RECLAIM_ACCOUNT|SLAB_ACCOUNT|SLAB_STORE_USER > instead of just printing 'accounted=true/false'. This patch is too > specific to SLAB_ACCOUNT. Any extra output degrades performance. For my task it's not important to know SLAB flags, I just need to understand, is current allocation accounted or not. > And if what you want to know is just total slab memory that is accounted, > what about adding something like SlabAccounted in /proc/meminfo? It is not enough for me. I need to have per-process allocation information. Thank you, Vasily Averin