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 0D178D0BB66 for ; Thu, 24 Oct 2024 06:57:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 43D146B0082; Thu, 24 Oct 2024 02:57:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3ED2D6B0083; Thu, 24 Oct 2024 02:57:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B6606B0085; Thu, 24 Oct 2024 02:57:24 -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 10C146B0082 for ; Thu, 24 Oct 2024 02:57:24 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1D4C512108E for ; Thu, 24 Oct 2024 06:57:07 +0000 (UTC) X-FDA: 82707588852.27.35DF49D Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by imf20.hostedemail.com (Postfix) with ESMTP id 6ECB71C001F for ; Thu, 24 Oct 2024 06:56:58 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=j2DJisqf; spf=none (imf20.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 192.198.163.9) smtp.mailfrom=andriy.shevchenko@linux.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=1729752889; 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=9JnU9J5l8lN0e4p83h5MANP+G/ADZAq7LSKvJTWck1M=; b=aGMjUaVMPODN9/sGeulljh2PwadjrOUvVTa92fmn/lRw0BZVEVKWANkzJ8zbX5zapZnvnf Bh97QymnXosvizuXvxFJ1ZzM3nz8IGf3r7qlO9CwbFUsCWhK3T1CTxDHMz8fY0kjxMxEXM L9PQ1SXFE96ANQbBx4HyVUPdNXbTiio= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729752889; a=rsa-sha256; cv=none; b=eiRN6DdUrfZU4AssKc/EON5Gwplyr3FdMkOye1IvRR3tBP6AISaoYn3k+rw06pjn3xSlmq 2DV4eYc7Ua/Efnl+NPX6ZRIqndCJrruiIL4I6Cs6ARu9E0RxXhSSoEeMD3kaDQtY5wKixN nagNetwou3L/vpSxyMUvoQ6/GVeDZnE= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=j2DJisqf; spf=none (imf20.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 192.198.163.9) smtp.mailfrom=andriy.shevchenko@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1729753041; x=1761289041; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=HEG5AppcH8Omlqn6dqBEOOVtSw/qmfp62vOEhiOJa7A=; b=j2DJisqfgsW+LB8ggvDT7ZFtyC9ziUexqql8y3dcxMS2MvMOFoBMpjoO J79R1O6bjPcNVhkgOP7cT49EZ0aQanHjEoFB0sN8KXcTHpfHYw0QTLUcp 1AvCr2wHozYA2tLvbPKsIhfCMBkToPwqy3FbrJopZFNKuRKjZeBOa66+5 Gzimfts8YLfNBHkhNfcQ9PX0NGd+b/VuBq4sgmS0erw3Xuxp0H8hUZnIa Sd0JdrVcR97Sc/6HFMkY9GbRl/bKvA4yiqFIslfW+lC9O3IuiYnq7rgRz Cb8A/D0HLjNTiKfu94ZhZLusFHigrJLJCG83UEcoRThKvzNBe5B2ZQsqp Q==; X-CSE-ConnectionGUID: eF6xpSZvRY+7yOoXECEFAA== X-CSE-MsgGUID: Yw0xMcHsS+S5L6T+A2YzAQ== X-IronPort-AV: E=McAfee;i="6700,10204,11234"; a="39979955" X-IronPort-AV: E=Sophos;i="6.11,228,1725346800"; d="scan'208";a="39979955" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Oct 2024 23:57:19 -0700 X-CSE-ConnectionGUID: Sd9fHMOjSUOoo2kjypeU7g== X-CSE-MsgGUID: yNoH64OFRuW/PaET0dNstg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,228,1725346800"; d="scan'208";a="80160070" Received: from smile.fi.intel.com ([10.237.72.154]) by fmviesa007.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Oct 2024 23:57:16 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.98) (envelope-from ) id 1t3rmS-00000006Tym-1cq6; Thu, 24 Oct 2024 09:57:12 +0300 Date: Thu, 24 Oct 2024 09:57:12 +0300 From: Andy Shevchenko To: Dan Williams Cc: "Huang, Ying" , David Hildenbrand , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, 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() Message-ID: References: <20241010065558.1347018-1-ying.huang@intel.com> <87set3a1nm.fsf@yhuang6-desk2.ccr.corp.intel.com> <671965a8b37a2_1bbc629489@dwillia2-xfh.jf.intel.com.notmuch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <671965a8b37a2_1bbc629489@dwillia2-xfh.jf.intel.com.notmuch> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Rspamd-Queue-Id: 6ECB71C001F X-Stat-Signature: uit4mt3epfztgzsx7etatdahtwfropo9 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1729753018-683674 X-HE-Meta: U2FsdGVkX1/9xkJJBqxguyBzclMquAFlhVpKLDP0OBIE/vbJGEXyH7/Iu9bwfArBIuigvmGFKuI2uvkD3IMrAZjFccsMp/cfa1cjiNfDCWL21V+QW4lG1j/v+ciwvPG8yVjDQ0XQoWzA1ApELKUWKonRpuUHcuTfMi1oIDYQlavYhx1kDHYFvdujiG4W2RR04qDpNaWo9elRebhe0982KJGkdWNbqQDbDG8XKO/qp426f8UpibGFIDvPkM/iO7p/qm20Z1nhDOU8WaO1HGAP8GaDYHwQrNFvoB5bvQcld/HK/UfIwopWMYzEIjCQlgLJ5wiiFEryKGNBWdh9CD7RjfP1mRzxw7N/KLUlZwOK57oI7G008LmzJwMuT9108G/N8Hx9INnPqmVcyY4zZdV3i8uiX7wQ8qVATguibSfHqww+zDTrAtbCZ6v9gHHGwoD4lWqIR7YInx4teR0vOOVcdvH+Th6JN0ymkjpInvt2XiyvY7MLomdjgbtOI+Jl8TsXV0hh4p++xPYCO1cU3ckHElWSFFoehNFcu+MHQP16J21HmGjf0JXPGoOEXHJBZVYZGEmJQ7wZMAAYaqSM7F4xnYWf5cz5Ncw1UAJaXG5tgalXKMTlDT4tpUIUMfAajhI94CFFaFuJh1ufvvtPk70xCoXbyl3W+YFdySTdFjVMrXjFy45OAIAwCgQbJj+RIrRKWVY9XVPZ3UNcrbGsf376Nf7BrpVd58Iafb/4JtlHkc3uTnhBEANhAQnusGA1yMTgM9q3nBzjv8BtaI+L3iBKN8EdZLRTINBlZSOOOdoPTJXQ68tsu8KmZL5jd7lDEk9Wpqo50pKWvHr/JnFFpLvlqlLNvtZnmvastFYUikHfPlxPm6ELFvmtGLvFuNiJ9O6tmrTiKa5XXOudvOZ5lSmzr+YHrZ1Znnv4L1xQhR1LXm7BI8ynYjvlRTdcc4j1YWbYtAcJIv0tjFC+DRbBPro L0sfNw7M OlowhGAkimo4RdSp0bFKxB00h8uommQqxzcN4nsuTL90vxsMrYyCMaBCRoB+OrUj674kY2yZ4n+FJcFakdwqf+LMZA9jIbUDGd4QNC63Wr2RXX9UhLsumlr4ggtJaXXYJoTm/uAT71aXHq7YcBnwWCBLfbqtT1vR/TklCS6H+oIBm7XvCHnmwkJ7cPDj0kmXTcaZxZ28c/aCU/v/B9QAqxJpALKtHMzAbxau7Hdrz3iS9CykLAmI3UG46HaDEACa2jtO+wsRdyuso2HJNByLP9I9fBLSF+b34A342UtsKDd910g0= 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: 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. > 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. -- With Best Regards, Andy Shevchenko