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 C5F6FCE8E6D for ; Thu, 24 Oct 2024 12:34:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 060296B0089; Thu, 24 Oct 2024 08:34:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F2ACB6B008A; Thu, 24 Oct 2024 08:34:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA4786B0092; Thu, 24 Oct 2024 08:34:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BC1186B0089 for ; Thu, 24 Oct 2024 08:34:21 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3A3C4412B5 for ; Thu, 24 Oct 2024 12:34:11 +0000 (UTC) X-FDA: 82708438512.28.CA4E3EB Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.14]) by imf29.hostedemail.com (Postfix) with ESMTP id 467F6120008 for ; Thu, 24 Oct 2024 12:33:53 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=JMLwbyLY; spf=pass (imf29.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.14 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729773055; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Kp30WQet0Kfdedv9gTtp7iiGBYp1ClwoXTi70k1rgVE=; b=YrSnMPnIXSHdYzz+MfT8a3WxIYPHf55Mh+p4LrBDi02iEa+wEEjO3FpPV1cmoKXIO4kHV0 w737UQT6Hvw3yese4oo8KdoKBOhI9uVnCjM8ZqomSR4otJCkZ5lk8VKCkkH1cFJlrpTVFE Fl7RzBo9ftfZ7eHYTK5DYNPsUMqUGm8= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=JMLwbyLY; spf=pass (imf29.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.14 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729773055; a=rsa-sha256; cv=none; b=i3xQJ0uPZ3EZ89f2t3FQilleuGCg7nHp0tTXFM/KhOfryLZDT6xTXbyNiVAV1o3FHmKT+X +3NJY+b4ddLhHA+BKHVPVKZkWxZ5BC2YTlbMY54EkU2HB1zgpfwG30LUHMVhSFyT3Q1xKJ NMHVBQ1ULgLZQSjf5eD1ojQYMwdgYc0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1729773258; x=1761309258; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=CmAdV9afLS0JTDf0VeXFhYzLWX7ZMh8xBb4mg2UTXtU=; b=JMLwbyLYUO6nL45gx+fRlqsddVcH5gWIWxms9IC6BpBLZtfNoInBhGzB WvkeFXUdzTb4lecYtcEsO4a2QyZy7QAtQDGCzS7iqmREjM2YclQOGtZAr M/JfCz5Y02/FgEHXU8sINM60X+yuiT+O307ySQYy5htzZwl409q9sSx79 ie3D0R31xUE9YBKqqdaaX4QiagXNuNSyFwz6HDIAVJnrr+CgukNT0GHeC NtrnB+b8JvWmgVyhMMEGNTFoe9mrNBzDhYGcxoMeOiglTn6pmQ0tz8ept JqiKFMna4GwmQmbkuFBxaa9xjBwEMf3rrSvdUHV+5ncIQxRzHLUnqnRNt Q==; X-CSE-ConnectionGUID: 4I7e5xenRBSOr3ldLD6N5A== X-CSE-MsgGUID: ALlqVqXXTCOCXwxiABZxUA== X-IronPort-AV: E=McAfee;i="6700,10204,11235"; a="29619410" X-IronPort-AV: E=Sophos;i="6.11,229,1725346800"; d="scan'208";a="29619410" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2024 05:34:16 -0700 X-CSE-ConnectionGUID: dCkiNN/zRvihLsXoCaBq7Q== X-CSE-MsgGUID: FCI6bu98S2uJetZqSIW1oA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,229,1725346800"; d="scan'208";a="81395591" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2024 05:34:13 -0700 From: "Huang, Ying" To: Andy Shevchenko Cc: Dan Williams , David Hildenbrand , Andrew Morton , , , , Davidlohr Bueso , "Jonathan Cameron" , Alistair Popple , Bjorn Helgaas , Baoquan He , Dave Jiang , Alison Schofield Subject: Re: [RFC] resource: Avoid unnecessary resource tree walking in __region_intersects() In-Reply-To: (Andy Shevchenko's message of "Thu, 24 Oct 2024 09:57:12 +0300") References: <20241010065558.1347018-1-ying.huang@intel.com> <87set3a1nm.fsf@yhuang6-desk2.ccr.corp.intel.com> <671965a8b37a2_1bbc629489@dwillia2-xfh.jf.intel.com.notmuch> Date: Thu, 24 Oct 2024 20:30:39 +0800 Message-ID: <87wmhx3cpc.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 467F6120008 X-Stat-Signature: 3q5p88dgazimh85qnnuz6yr67ns6g6cw X-Rspam-User: X-HE-Tag: 1729773233-780877 X-HE-Meta: U2FsdGVkX18DSaxh/of0T/Uzunqm8p1ZFMdRxs1hn3NKl3+J/K7e1lz4NlnKmXs97dTS9hM7/7IBDAV6mVaa2uVfDR+WQ8DwVUnXMNI0qt0WDIzB0Zs/u9DMUIJC8S5/OR+GL32YrTW1/rsFOSC5AT3A9e+kNrmbvxF+kCltKWPE55zHWaxq0J52WRryyKaWwb4Z/GojOe60XSIUzR4iawTNwFnUKzjON4BMqbK6FCE0+e8TWy28j9PR6HhFFXgHrUtRPq99awK+PkXir/4k34Yq/sUOlo0OiLaOJqpba2H4LquhChfgd3XbMw58VvYLiHCMEagUEYCdftoXLlh9Yj3o9EeV6otr/rDe5LJpbCGqrUytpxn3lSDpuGGbo3eeaRpSLZ1ghstTkwZyslVv9zXnnz6Qmkajsjw5/O9rrqW+hkaMmvMnA7YokLwGMaXXDRKIdLUVoZW6/S1tqwetQhbfJuDG7N6nn9TpOF0pLuwYSnqoKpaKpEleueseZdD72gqXwWOp0ffKz8wCkcNmM2xuYY4VvooomGkFLAbMjvayfZ+iHiMAggqBDQuZMmK6g/q7mxd3RQH818V/qNQlSBqxTTleka5H6RhwheyKrjX+EdHqtpi5kM+tF45SKZkBkLnqtbiJHBObCvwwSvSh0oq5Ud6+/gyKv5S87ba0RLcIBVgh523QT4wWnw8yTXIP5aho+EouCrpHZwn21OyImY5iKVyXqg83mjlpzn6X+aZt9TDoMpP81EGm/geHDZxyw5R8q7yuTqN7+wOSdtcEbwNLdi0ZUUwAtOAATvTTBQpH7lqKvngrwsw8jQi9M3SdUwwebBuQMVb4wEcHAnxedxe9NG16eL2N6yWBVQGzj7Gh9p/MfWWesa1PZVXuQs14V9q5YOKR/paqLtzP4H/r/YaYHU40ixcv+pb9wrYoC0yOGGiW/tcItuf44c5BZz6DrDDG8mbkkZhe5yoVTzi EJiGFbFF 138l/lm48FeW09F8IxsSj64mT1zvy0DlsizUfCSw6x/PL5voJIm+CnZcS6mLXawbptQoOEee0eeNc/2/xvsXHML+02Yv1MysPsDGJ9IgyNGpjhzYmJLdwU6jc0LHGt65/l7lkv3QFwDL30xHjK2Sne2ypSzVzruQdE/1EtPTAanEW6APpVpWTgYMCstSl65qkxtx+7g49lizDh+9Ti696L5bDTHW0k91TdHg9ADx/Tyo+k43VjkQ1aICtcSndi21jF3WxypUtyTPIK5g= 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: Andy Shevchenko writes: > On Wed, Oct 23, 2024 at 02:07:52PM -0700, Dan Williams wrote: >> Andy Shevchenko wrote: >> > On Fri, Oct 11, 2024 at 09:06:37AM +0800, Huang, Ying wrote: >> > > David Hildenbrand writes: >> > > > On 10.10.24 08:55, Huang Ying wrote: > > ... > >> > > > for ((_p) = (_root)->child; (_p); (_p) = next_resource_XXX(_root, _p)) >> > > >> > > Yes. This can improve code readability. >> > > >> > > A possible issue is that "_root" will be evaluated twice in above macro >> > > definition. IMO, this should be avoided. >> > >> > Ideally, yes. But how many for_each type of macros you see that really try hard >> > to achieve that? I believe we shouldn't worry right now about this and rely on >> > the fact that root is the given variable. Or do you have an example of what you >> > suggested in the other reply, i.e. where it's an evaluation of the heavy call? >> > >> > > Do you have some idea about >> > > how to do that? Something like below? >> > > >> > > #define for_each_resource_XXX(_root, _p) \ >> > > for (typeof(_root) __root = (_root), __p = (_p) = (__root)->child; \ >> > > __p && (_p); (_p) = next_resource_XXX(__root, _p)) >> > >> > This is a bit ugly :-( I would avoid ugliness as long as we have no problem to >> > solve (see above). >> >> Using a local defined variable to avoid double evaluation is standard >> practice. I do not understand "avoid ugliness as long as we have no problem to >> solve", the problem to solve will be if someone accidentally does >> something like "for_each_resource_descendant(root++, res)". *That* will >> be a problem when someone finally realizes that the macro is hiding a >> double evaluation. > > Can you explain, why do we need __p and how can we get rid of that? > I understand the part of the local variable for root. If don't use '__p', the macro becomes #define for_each_resource_XXX(_root, _p) \ for (typeof(_root) __root = (_root), (_p) = (__root)->child; \ (_p); (_p) = next_resource_XXX(__root, _p)) Where, '_p' must be a variable name, and it will be a new variable inside for loop and mask the variable with same name outside of macro. IIUC, this breaks the macro convention in kernel and has subtle variable masking semantics. >> So no, this proposal is not "ugly", it is a best practice. See the >> definition of min_not_zero() for example. > > I know that there are a lot of macros that look uglier that this one. -- Best Regards, Huang, Ying