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 976B6C433EF for ; Fri, 20 May 2022 07:29:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1F9A66B0071; Fri, 20 May 2022 03:29:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 183BD6B0072; Fri, 20 May 2022 03:29:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0237A6B0073; Fri, 20 May 2022 03:29:47 -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 E45BE6B0071 for ; Fri, 20 May 2022 03:29:47 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id B1B071214B5 for ; Fri, 20 May 2022 07:29:47 +0000 (UTC) X-FDA: 79485296814.18.2E6D60E Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf25.hostedemail.com (Postfix) with ESMTP id 2A7F5A00C6 for ; Fri, 20 May 2022 07:29:22 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id BBC6921C7D; Fri, 20 May 2022 07:29:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1653031785; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2FXv1dgsYTKaim0NgoOrpNGccWSrMRNDM5AkhS49DWs=; b=ICaJn67v2gF2PbSdCTsQnIvjMmEX8BOujrOgBrm1IrKejCLRT2BWNVjYuxOqMjlOka2Nqz 7wtGCPO6Sxp1pEmkwsIMETuaaY6rFSzNG87SEhJVlW39uk3W3fStPgzu7TcgzJ3GUInpR/ zvEq7wTmasM4aS/PdC3GaIQxnkBiT+4= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 3079C2C141; Fri, 20 May 2022 07:29:45 +0000 (UTC) Date: Fri, 20 May 2022 09:29:44 +0200 From: Michal Hocko To: Vaibhav Jain Cc: cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Tejun Heo , Zefan Li , Johannes Weiner , Jonathan Corbet , Vladimir Davydov , Andrew Morton , "Aneesh Kumar K . V" , Shakeel Butt , Yosry Ahmed Subject: Re: [PATCH] memcg: provide reclaim stats via 'memory.reclaim' Message-ID: References: <20220518223815.809858-1-vaibhav@linux.ibm.com> <87zgjcg4xs.fsf@vajain21.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zgjcg4xs.fsf@vajain21.in.ibm.com> X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 2A7F5A00C6 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ICaJn67v; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspam-User: X-Stat-Signature: sssh35we94xwfm313u5o3p7t6yjnhhuh X-HE-Tag: 1653031762-997523 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 Fri 20-05-22 10:45:43, Vaibhav Jain wrote: > > Thanks for looking into this patch Michal, > > Michal Hocko writes: > > > On Thu 19-05-22 04:08:15, Vaibhav Jain wrote: > >> [1] Provides a way for user-space to trigger proactive reclaim by introducing > >> a write-only memcg file 'memory.reclaim'. However reclaim stats like number > >> of pages scanned and reclaimed is still not directly available to the > >> user-space. > >> > >> This patch proposes to extend [1] to make the memcg file 'memory.reclaim' > >> readable which returns the number of pages scanned / reclaimed during the > >> reclaim process from 'struct vmpressure' associated with each memcg. This should > >> let user-space asses how successful proactive reclaim triggered from memcg > >> 'memory.reclaim' was ? > >> > >> With the patch following command flow is expected: > >> > >> # echo "1M" > memory.reclaim > >> > >> # cat memory.reclaim > >> scanned 76 > >> reclaimed 32 > > > > Why cannot you use memory.stat? Sure it would require to iterate over > > the reclaimed hierarchy but the information about scanned and reclaimed > > pages as well as other potentially useful stats is there. > > Agree that "memory.stat" is more suitable for scanned/reclaimed stats as > it already is exposing bunch of other stats. > > The discussion on this patch however seems to have split into two parts: > > 1. Is it a good idea to expose nr_scanned/nr_reclaimed to users-space > and if yes how ? > > IMHO, I think it will be better to expose this info via 'memory.stat' as it > can be useful insight into the reclaim efficiency and vmpressure. We already do that with some more metrics pgrefill 9801926 pgscan 27329762 pgsteal 22715987 pgactivate 250691267 pgdeactivate 9521843 pglazyfree 0 pglazyfreed 0 > 2. Will it be useful to provide feedback to userspace when it writes to > 'memory.reclaim' on how much memory has been reclaimed ? > > IMHO, this will be a useful feeback to userspace to better adjust future > proactive reclaim requests via 'memory.reclaim' How precise this information should be? A very simplistic approach would be cp memory.stat stats.before echo $WHATEVER > memory.reclaim cp memory.stat stats.after This will obviously contain also activity outside of the explicitly triggered reclaim (racing background/direct reclaim) but isn't that what actually matters? Are there any cases where the only metric you care about is the triggered reclaim in isolation? -- Michal Hocko SUSE Labs