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 0FEB4CD3423 for ; Mon, 18 Sep 2023 23:26:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A9A86B0447; Mon, 18 Sep 2023 19:26:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 632806B046E; Mon, 18 Sep 2023 19:26:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4AC1D6B046F; Mon, 18 Sep 2023 19:26:23 -0400 (EDT) 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 357236B0447 for ; Mon, 18 Sep 2023 19:26:23 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 046651404C2 for ; Mon, 18 Sep 2023 23:26:22 +0000 (UTC) X-FDA: 81251304246.29.D9BE7E9 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id 282A840028 for ; Mon, 18 Sep 2023 23:26:19 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rcf1GV3g; spf=pass (imf27.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695079581; 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=kVSc03zT8Jzi+8PHbyIze7kfmXDlQFmIz1i3GOissAk=; b=P9RwR0n89uukJcNSSq3CsJFoL3XoHR4GTF9BTDe0qpjUJLOniR53ZwUwLICblF8+4/x6tV Uy4XsXKsel7gLoTyPuue+BSUnj5YHjn1jrtsXT0OSGS3MVD8l9CFQ8JLKYRa8M0goxkhWo vLDXi7X0gB+dEsI9UU/rESoZCeVvJGc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695079581; a=rsa-sha256; cv=none; b=Fuvuk02gd3c8OdtXq/PD/0dL7+f8dagf1D7MOT4T/ci94sM23rJF2vD+NEoPmu26XnSaxj hhw/T10H81FwI6GY3p05wQ/uSF7GR6ESjWcskPJGrK9w1hqFLMIaYrjxXRPHjAFlJvkvJa UHKR1xPrA98qDi1WF4jVsQTS2TFFP1U= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rcf1GV3g; spf=pass (imf27.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E05F9612CB; Mon, 18 Sep 2023 23:26:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 747A5C433C8; Mon, 18 Sep 2023 23:26:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695079578; bh=w+5TKw8eUWwc8FHE2rQiN6hONxiw9+38NV0cSqf+vKI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rcf1GV3g9AXCbaBrCamMwmbJMPgdvctzIvLG4CXdC43p/yVVvJUEkS9nLhTkFTZPm a1aNoKayVy+1yroTYwgXBHOBKVbJms04hxop74czjslZWfNOq1z2qncZfp4hBQTbtq YQHlZi6bHJxnwo7ls2HE0RB/Y8DaKbTthdP34a8U35/qd/SVqvkAESGXdNvwgzS1G8 QZ4Fc8bzkHEZzlJzbGbYpDJsd81kCEMy8fXSmaLIr4hON6tjFLlQEIyzOmwje9y3Pc x9kwBoMyf5Kf7P1Txe+fYpaL2pjEOSGhwu99O97oBwVR35+sFzXFuEqKA25lX+EPVF bOCKkfEJsG+0A== From: SeongJae Park To: =?UTF-8?q?=E6=9D=A8=E6=AC=A2?= Cc: "SeongJae Park" , Andrew Morton , "open list:DATA ACCESS MONITOR" , "open list:DATA ACCESS MONITOR" , open list , "opensource . kernel" Subject: Re: [PATCH] mm/damon/core: remove unnecessary si_meminfo invoke. Date: Mon, 18 Sep 2023 23:26:15 +0000 Message-Id: <20230918232615.60499-1-sj@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <2feda3fb-7306-4ee7-9be3-a3990b6e9c43@vivo.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 282A840028 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: ech8ud4yqyw1eieay8fmryhx6mengunj X-HE-Tag: 1695079579-284829 X-HE-Meta: U2FsdGVkX1/dvHyp11RecPopJlfonwE62tihwxL/jqzBnJh/FvWV2gOKJFgrZLY23S1mJm78WGmQ3P25DB63U8sO6ylUFi4f6vdCunRB3LWbgjjvljYgVY6gwc9M5MJF0pz5qSgBpHJQDA6PA+NCq2vKmqeTTBHbzssa1GJNFlqAS3W50Oyl5UmfCvnmROh/2L9sE2eyhp4tw8Dh3Pw82k/owSQr7E5vuINA3L7xF7EPvnoyX0UaF/hmFSBpIpgPQoBuS4aXW9FQay6/ERP4y1jBfNSqjxE5V50C3O5tRRTV1POYvtW2zG1jlos5WjJ/PsI0+khSqu9VLzZc9oEiMP++7Te6jFbkhoNWvgxbXYXSihNWeG6T5pS6yhXLq0MuO6ZhPa6eIks3S0wx/WwYJyKED27vcPcotERzUFisTPl2xmwzenwQ3oEwh3qfuHxUG8DBE1pZlO5qTsuVEyCNgLyvCOjsWcUMsONoF00++5lEW7HBbmCwXB/ChtLmrYyMC2TyCgUr4+RDBN744A15A3DZ0KxK/NcfCQb2xHSs2Xp+O7fr5ApbjWtYeq/6XcNT/4T+A8KCG7HyGYgy/EpdAX651qbFOnS50HQ8r1EHEmy/TxbCs2UEIX0HxrzFWplbZU9bwWUwbYjrvZm8QVH+CfrU/GpMMbfOEwT2L8VUCkXua68HHs5aq39EMA3TvUToGgHf4vdU4LoMeHWTOd4nuvH4fT59XYK7Dixo6uRZxX5s/OQSQ4KH5QC7vymsYdk6pF8BqXLyMQlfjD+Fu91FkPSc9Mbwij4cT+rjLc4oas6oDDlFKv7ZpUeAV8xjL2zjyIsb8DzC8QMFBkgmC0bFiGtM6lat8RRRzbzSYt1Jh46dEKUNo1AMmg0Lj09EvAg+sPyr73bJmJhGZlIiGH3LVyoP884nrGgaPxekrrMG0EuKmEFQS8T0o4AdFHMZSej13ywesIPZp+ytHLSgBVS Pv45RO2Z QvpA/V93dQzSG/JeYLBnGQkeu98yS9fb/LOqLxMO6kDjT2kUwOThZbmM8f+dKxTAo3leh9vGytweP4ru1CpwBZnBU6DVlBhyHXYV3g3EbqhByEufPvelfcAp7QmiWBL94vP6cdgOe/ILcrP/olqKD2aJsuU00dUP9uy4eXAhAgGkm8CVMECq2+K/BsYrnleDL3fJ3Z77wvQ7bTWfov1+2FLal9ztcSI9g8MeOCv2UQwtjfvBwX6+AiVPk6eq/Z+iZoxY5WXlJANqx5AdlZMc2YuxsOL8mFwBvExPHO6b/FsQU/zlsLkmOZ2DBg0yCKMPK2CM7ZFtbUp3Dsp+i1HMHMUsNgC0SQg3+GgzQ4kLLWGlIOLlxGaVkuz13BWksa8yCg2gvPYUp4PQCwUk= 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: Hi Huan, On Mon, 18 Sep 2023 12:12:01 +0000 杨欢 wrote: > 在 2023/9/18 20:08, 杨欢 写道: > > 在 2023/9/18 19:11, SeongJae Park 写道: > >> Hi Huan, > >> > >> On Mon, 18 Sep 2023 17:49:34 +0800 Huan Yang wrote: > >> > >>> si_meminfo() will read and assign more info not just free/ram pages. > >> Nice catch :) > >> > >>> For just DAMOS_WMARK_FREE_MEM_RATE use, only get free and ram pages > >>> is ok to save cpu. > >>> > >>> Signed-off-by: Huan Yang > >>> --- > >>> mm/damon/core.c | 10 ++++++---- > >>> 1 file changed, 6 insertions(+), 4 deletions(-) > >>> > >>> diff --git a/mm/damon/core.c b/mm/damon/core.c > >>> index bcd2bd9d6c10..1cddee9ae73b 100644 > >>> --- a/mm/damon/core.c > >>> +++ b/mm/damon/core.c > >>> @@ -1278,14 +1278,16 @@ static bool kdamond_need_stop(struct damon_ctx *ctx) > >>> return true; > >>> } > >>> > >>> -static unsigned long damos_wmark_metric_value(enum damos_wmark_metric metric) > >>> +static unsigned long __damons_get_wmark_free_mem_rate(void) > >> Nit. s/damons/damos/ would look more consistently, in my opinion? > > HI, SJ, sorry, what's this mean? > > Haha, I get, yes, damos is better. If you agree with below, I will > resend a new, rename to > > __damos_get_wmark_free_mem_rate. > > >>> { > >>> - struct sysinfo i; > >>> + return global_zone_page_state(NR_FREE_PAGES) * 1000 / totalram_pages(); > >>> +} > >>> > >>> +static unsigned long damos_wmark_metric_value(enum damos_wmark_metric metric) > >>> +{ > >>> switch (metric) { > >>> case DAMOS_WMARK_FREE_MEM_RATE: > >>> - si_meminfo(&i); > >>> - return i.freeram * 1000 / i.totalram; > >>> + return __damons_get_wmark_free_mem_rate(); > >> > >> Since __damons_get_wmark_free_mem_rate() is just one line function and > >> damos_wmark_metric_value() is the only user of the code, I think we could just > >> writ the code here? > > > > I do this in mine first patch, but then, I fold this into > > "__damons_get_wmark_free_mem_rate" > > > > due to I think the "__damons_get_wmark_free_mem_rate" may change the > > meaning for furture, > > > > and may si_meminfo will come back soon?(If we need more info to get the > > rate?). And, also, the > > > > static function If just some user use, it will be inline, so, I just > > think fold it will be better. > > > > Do you think so? Unfortunately I don't think so. What would be the future use case that would require changing the meaning of the metric? I cannot imagine those off the top of my head. Even if such use case is found, such change would be a user-visible behavioral change, which we would like to avoid. If such change is really needed, I think we would keep the current metric as is and create an alternative metric that having the new meaning. Anyway, we can think about such case when it really happened. Also, the current code is doing the calculation in damos_wmark_metric_value(). If there is no specific reason to split the logic out to a new function, I'd prefer keeping the overall structure as similar as is now. Please let me know if I'm missing something. Thanks, SJ > > > > Thanks, > > > > Huan > > > >>> default: > >>> break; > >>> } > >>> -- > >>> 2.34.1 > >> Thanks, > >> SJ > > > >