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 214D5CFD34D for ; Fri, 11 Oct 2024 11:19:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A5C4E6B00AF; Fri, 11 Oct 2024 07:19:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E3986B00B5; Fri, 11 Oct 2024 07:19:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 836876B00B6; Fri, 11 Oct 2024 07:19:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 5ABF86B00AF for ; Fri, 11 Oct 2024 07:19:49 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C4D42A0CED for ; Fri, 11 Oct 2024 11:19:40 +0000 (UTC) X-FDA: 82661076414.13.C0C6E9D Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by imf03.hostedemail.com (Postfix) with ESMTP id CCCC820009 for ; Fri, 11 Oct 2024 11:19:44 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=TIAzab1I; spf=none (imf03.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 198.175.65.15) smtp.mailfrom=andriy.shevchenko@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728645515; a=rsa-sha256; cv=none; b=3EoAbuFVVBymRcRtWj0ThcSzvfcWxmTogKM/ZwXmZQCdvdbV7W5y/TkMMqFANpVFFlN8Y1 WQeYyvkJDfUvMXeUPw+xQUf5tr0E8Npus5tSEu4/1FIdIf+/fkMqF+Cyx8Upl0BYsBrhiM jf31fygGGyjyRDHRc5GZM+7oKyhwMUM= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=TIAzab1I; spf=none (imf03.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 198.175.65.15) 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=1728645515; 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=1boxMF4e9UsruTcwwzq49/1zIGIeKf5cquwYonnRN2Y=; b=cfxPfHjA74cVeIMs4UWrNBbiubPW+3XibjUc8X03rsWGt1y6teZR+vPfRFIXK6AMuZR+3o GZkFeFrbOv6hFSOIYe/rUWUBm7l8MF6Yx2V3WaGHuhoZv5wsentAXdd1t3dHimP82+Jvdd ZFCG3gLZ2gg26DT076s9fNlpuuJ21ew= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728645586; x=1760181586; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=it95fUgt7wvO9ItiFN1pzO9CyA8MDbxEdlRQ+yGcR6A=; b=TIAzab1ITtIVE9wznA7pNr5r7gR3pYK3I/2AqIjnUguUHBFDVkVIIL9a a9azMepBXaTP/To88Vfw5tXTMXWCqbMoozRFQAt5pQpWdiel+wMb4F9lX /wqJpzBi5hPx++ZS8wNZO0r5bnXvXB0EeciV6X3ml0gc/QdQrOMhjyoym IPcQ6hsqyVgHAgk0i8AMPR0THc8i5hjDPZDM0yZkbK6a0F+zvO5vpvR9b eq2sTqPboJiFfgvWUGCZeA0LwLNstynE2WkdL9vyaZBENlpadO6frD9UU fD8m7lMV1MuL/OZ210+KJc9Y/RzcDaAom05B05UCdPnOrXD0KB6V88I0Y g==; X-CSE-ConnectionGUID: FooGYWtvTtO9aepNlczmEA== X-CSE-MsgGUID: eGGYHFZxQwGUc1+lZ5lpRQ== X-IronPort-AV: E=McAfee;i="6700,10204,11221"; a="31742004" X-IronPort-AV: E=Sophos;i="6.11,195,1725346800"; d="scan'208";a="31742004" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Oct 2024 04:19:44 -0700 X-CSE-ConnectionGUID: eCCQEYFeT7O11yPccr82Xg== X-CSE-MsgGUID: Hu6++5klQVmiU336eoBLJA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,195,1725346800"; d="scan'208";a="81403763" Received: from smile.fi.intel.com ([10.237.72.154]) by fmviesa005.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Oct 2024 04:19:40 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.98) (envelope-from ) id 1szDgG-00000001sCk-2cOi; Fri, 11 Oct 2024 14:19:36 +0300 Date: Fri, 11 Oct 2024 14:19:36 +0300 From: Andy Shevchenko To: David Hildenbrand Cc: "Huang, Ying" , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, Dan Williams , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Stat-Signature: 15cwtedbdoethgxbu95nhg4sgcs3ugic X-Rspamd-Queue-Id: CCCC820009 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1728645584-843183 X-HE-Meta: U2FsdGVkX18FWzpYbZXR+iJneY5s9bGg6mCSgN26jqN94Ul4b1XbVu5eY8phAaxB9Kcr+9ov0y2+f9fi4ZE9/UlDQKXekeUEdI6UOi/liAsZTh3H9sw0gpaQTh4TdafUG4CD8GL43e5fNfwMGyadefhIrTQyT3KGIxCN50z2g7152mhgC/0Sg3DCigoMZiZaeHt3t8L86JaNnzvFItpUXJ4DqeTyMAg1OAt2TRCOXRhlr4ACJKt6I9Cx6A8D5zIWA3WS5huLP/l9F7CCrr4WYlLAJdvuqZQhFpucQNV9djWSdKT/dBFiFZL3iO4clZ4wvbR4Vx+eUbAmR8SgHibkg1jw0NwF5Nh8QE1SdMHatBYb1wmF9cErL5B9WR5QwfGqgKR7U4mZGvopjJCjIE+u0TLagevuHKn/TcJxaW1uIALqbnIuTEjUkljszIBYd6JR2vTcszr1/h9HHioEY9bNiNI4q75+NeOJG4rJDX9c6WFOQte6eVE5BKw8JAHdWno3wLj4kMLdc3m9Tg0Z+SqOLWHUdlRYlaUiLLxr7K0JQBrOX2TFSU6RhkpPIqAUuRMyh3iyeeAazd5ixaWRYMl8CtDIpx3nJdAjF2I5EqXw4hUTZCPXmdw3nFrSk4raPPz1wQEFf0900mpb2bQZF68+nmvnQezyWcSvmg2uPIHyuWKXsZF2ufmXfBQVs6DPChOz58J3dgPcU7lWTT3lSWa7nGDS7vnep1zXX0TOJQRub6Lre9OiMHIOxgEvgscJajxEzWBOEhMVOAT7jQoiQtdzGa5cV4MGsBhkz0MOgwkqxw1EhbrLGIRgdXJIS/h+CyHR48CE2J9PLtuka6G3gtED9I5eAojEzzpy8KuTFjFVmAIN7EHs82edAlPzLJBbIULUeS9/8sMS93RYAbVPLHMhrPa2gOZssNFbT0SY2DgPa4MHRntnTECHCFHK+boOZZaTTfMe79MTp5WSZ5XaFbw yVYvfEkf zUixaREXi+PeFToGNp/wD/NLuMGWFhuITAHbq/83CH4JFOruH9kot8HLG/G/Ybyn61U3YQizts+8pcwyAp+xB7cirsG7292GYpmvEXkh+VeVP6ncoIIR9WyrJMTxVxDzj6/f6Qe2mhcp/U34XRSXBkb85Bm2kr9uq3bdn+XE11FkLPkJf0S0WECRHglp4na5riL8l3xoHHjvogjoL//b8KqF1UZ/gGoNRAw9FvjwKFE3Ws281fUsu4zKJaLJRGMsM5Oxz8bZcVLAlyb4+WowQajc2L1IzeittD/nTAcIRiojeEoU= 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 Fri, Oct 11, 2024 at 02:15:55PM +0300, Andy Shevchenko wrote: > On Fri, Oct 11, 2024 at 12:51:09PM +0200, David Hildenbrand wrote: > > On 11.10.24 12:49, 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). > > > > Fully agreed, I didn't quite understand the concern about "evaluation" at > > first. > > It's a basic concept for macros and a good mine field even for the simple > cases. > > > If it's just reading a variable twice, it doesn't matter at all right > > now. > > The problem (even if it's a variable) is that the content of variable can be > changed when run in non-atomic context, i.e. two evaluations will give two > different results. Most "simple" for_each macros leave this exercise to the > caller. That's what I also suggest for now. For any context as Ying provided an example with calls, they have to be idempotent, or you definitely get two different pointers for these, which is bigger issue that what I described above. -- With Best Regards, Andy Shevchenko