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 56F02C00140 for ; Fri, 19 Aug 2022 02:48:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D927C8D0005; Thu, 18 Aug 2022 22:48:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D410B8D0002; Thu, 18 Aug 2022 22:48:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C30D38D0005; Thu, 18 Aug 2022 22:48:04 -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 B2F828D0002 for ; Thu, 18 Aug 2022 22:48:04 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8A21680A0E for ; Fri, 19 Aug 2022 02:48:04 +0000 (UTC) X-FDA: 79814807688.25.EEA6971 Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) by imf21.hostedemail.com (Postfix) with ESMTP id 312181C00E0 for ; Fri, 19 Aug 2022 02:48:02 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R181e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045192;MF=xhao@linux.alibaba.com;NM=1;PH=DS;RN=5;SR=0;TI=SMTPD_---0VMe73D-_1660877278; Received: from 30.240.99.21(mailfrom:xhao@linux.alibaba.com fp:SMTPD_---0VMe73D-_1660877278) by smtp.aliyun-inc.com; Fri, 19 Aug 2022 10:47:59 +0800 Message-ID: Date: Fri, 19 Aug 2022 10:47:58 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.1.0 Subject: Re: [PATCH V2 1/2] mm/damon/lru_sort: Move target memory region check to head of func To: SeongJae Park Cc: akpm@linux-foundation.org, damon@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20220819022850.52236-1-sj@kernel.org> From: haoxin In-Reply-To: <20220819022850.52236-1-sj@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660877283; 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; bh=q9rMeLku1vr7JARisFXK/KXyfNINPcEuPAPI1h3aoE0=; b=OKr/glS4UXk2IEGJ2eHvovdQ4mdW5DtN5SLa5+JOhqouqdH43gabN0q/GBvvO66fxqYOf+ ygcnSWzyHfo6WkIADNzeNc4nKrHlz9RRCvxJW0/WcWk214H+3P0DYzjlOINL6SfswrmCon zXx6wo9UtUwrR+fu+LKG5I6Ux/pnDD4= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf21.hostedemail.com: domain of xhao@linux.alibaba.com designates 115.124.30.132 as permitted sender) smtp.mailfrom=xhao@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660877283; a=rsa-sha256; cv=none; b=nabQ3gdyeWrXtZxr81upwB3bpCT8s3JnwBbXukfi62NtGL3YumQzlqWFBy1m9+6ESunzr/ iy2tvaS2V+hx5ia+cmlJDyjGdLoP7Zk/t3Ii8YW187wx16v2q2Lwjgqcr/6Q+f32rkUA6A 9QIBwEwoNjIrd2J7Gvh4iB0dk3Zy16k= X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf21.hostedemail.com: domain of xhao@linux.alibaba.com designates 115.124.30.132 as permitted sender) smtp.mailfrom=xhao@linux.alibaba.com X-Stat-Signature: bh9ypj93ej1pyx8hfztb1aikuy674gct X-Rspamd-Queue-Id: 312181C00E0 X-Rspamd-Server: rspam05 X-HE-Tag: 1660877282-427167 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000620, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 在 2022/8/19 上午10:28, SeongJae Park 写道: > Hi Xin, > >> 在 2022/8/19 上午1:11, SeongJae Park 写道: >>> Hi Xin, >>> >>> >>> On Thu, 18 Aug 2022 18:57:31 +0800 Xin Hao wrote: >>> >>>> In damon_lru_sort_apply_parameters(), if "monitor_region_start" >>>> and "monitor_region_end" is not a valid physical address range, >>>> There no need to run the remainder codes in it. >>> The function, 'damon_lru_sort_apply_parameters()', checks validity of >>> parameters and construct the DAMON context one by one. For example, >>> 'damon_set_attrs()' returns an error if the parameters are invalid. So the >>> intended flow is, >>> >>> 1. check DAMON attributes parameters, >>> 2. apply DAMON attributes parameters, >>> 3. check scheme parameters, >>> 4. apply scheme parameters, >>> 5. check target region parameters, and >>> 6. apply target region parameters. >>> >>> Therefore what this patch does is making the target regions validity check to >>> be done earlier than validity checks of other parameters. There is no special >>> reason to check the region earlier than others. Also, this change makes the >>> flow of the function a little bit weird in my humble opinion, as the flow will >>> be >>> >>> 1. check target region parameters, >>> 2. check DAMON attributes parameters, >>> 3. apply DAMON attributes parameters, >>> 4. check scheme parameters, >>> 5. apply scheme parameters, and >>> 6. apply target region parameters. >> Ok, understand what you mean, my fix looks ugly, buy any apply above >> are not not necessary if one of them checks failed, why not check all >> fisrt and then apply them, like this: >> >> 1. check target region parameters, >> >> 2. check DAMON attributes parameters, >> >> 3. check scheme parameters, > The parameter values could be changed by users after the check, so we should > cache those somewhere anyway. In other words, we cache those in the DAMON > context. Therefore I think the above works were not totally waste of the time. > Also, because the parameters applying functions like 'damon_set_attrs()' does > the check and applying of the parameters together, I feel like current flow is > natural. Ok,  Thank you for your detailed  explain, just keep it. but there still a problem in damon_lru_sort_apply_parameters if (!monitor_region_start && !monitor_region_end && !get_monitoring_region(&monitor_region_start, &monitor_region_end)) if (!monitor_region_start || !monitor_region_end || !get_monitoring_region(&monitor_region_start, &monitor_region_end)) the '&&' should fix to '||', anyone checks fail, it should return ? >