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 C3A86CFD34A for ; Fri, 11 Oct 2024 11:16:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 354B66B00B2; Fri, 11 Oct 2024 07:16:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 303DE6B00B4; Fri, 11 Oct 2024 07:16:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CB776B00B5; Fri, 11 Oct 2024 07:16:07 -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 EF2A06B00B2 for ; Fri, 11 Oct 2024 07:16:06 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 21E5FA0C6B for ; Fri, 11 Oct 2024 11:15:58 +0000 (UTC) X-FDA: 82661067048.23.324E2BF Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) by imf14.hostedemail.com (Postfix) with ESMTP id 66C94100014 for ; Fri, 11 Oct 2024 11:16:00 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=BnBC8Yrb; spf=none (imf14.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 198.175.65.12) 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=1728645293; 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=MGs39YMU6p/PKeUv4uUNvR693i3+Kn35QbWJ94yKu9I=; b=mwifXvup0i5lTYBp4j6H4HFI1VOdupxkZHd/ZBrZhpWDROJYVMXMy6U+IQ1ekZjuLtFFKl 0aA1+D99QN082GHCjjx5qytt++aZ/87SBSkVix/3N4SmmcXCUxv2LFx18pRIAb2NCLD9LJ cNMtyn0dPlsc23Pma8yafe700kNbVC0= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=BnBC8Yrb; spf=none (imf14.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 198.175.65.12) 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=1728645293; a=rsa-sha256; cv=none; b=fnjPEw9h256G4QeOAnao70oTJPy6COdXAm/PhRoSPpZBzU2vfHRFlmzjBrNKPxzByEw1Dm Y68RlErjHmEnt4sLwRuJntUFoiVrObvllsWQuYE4hSUU5Dhs7Ci8lkrEL9UZTsH8Ou6tWy qXz4JfusbB9pT+DvwQe7PPDvmpUFRDs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728645363; x=1760181363; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=WHc863Te71zd6D6prIfqp6EVVtJ/33OJMkMFg8NmTzI=; b=BnBC8YrbLSMc0CySlfWkm0+otrBttHnvj2TTm9+73t9iE1s7lIuFaE9x 1O0ekUZ0FXYPHgxS15Frce0gPqKtIfmOWGgmoXaG22/nKfLheBQNg63TJ 7VdvXOFNiMpxgGAbXIdQ8ybH7Y5+d5KWfcIzoh2f9de8oLAvhE4ZlxckD pWLHdVXFcwI9gS6/dOnRAKguefdgBxn3Fmjie/OcvQW8kG/5ETp4jdQO+ fKT2FIdumjdHNYBaLZo/25nARbz06GpJT+HXcHLDFDiQ4qcWn6aawwL8m U44FTj7AGwJML3SbLgxlYYsW9KWq7kquqCGmpV9ckkeVBLI4YRuxcNL8u Q==; X-CSE-ConnectionGUID: D4c6GsuDTyiSfn7i+WkiIg== X-CSE-MsgGUID: iCYDQVu4TxGH6CSdsJ2oAQ== X-IronPort-AV: E=McAfee;i="6700,10204,11221"; a="39435474" X-IronPort-AV: E=Sophos;i="6.11,195,1725346800"; d="scan'208";a="39435474" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Oct 2024 04:16:02 -0700 X-CSE-ConnectionGUID: ThwDaXjUT7S9dbQ7mrq1iQ== X-CSE-MsgGUID: /VF7qMAARhS82qredpx+aA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,195,1725346800"; d="scan'208";a="114342236" Received: from smile.fi.intel.com ([10.237.72.154]) by orviesa001.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Oct 2024 04:15:58 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.98) (envelope-from ) id 1szDch-00000001s9N-1xEK; Fri, 11 Oct 2024 14:15:55 +0300 Date: Fri, 11 Oct 2024 14:15:55 +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-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 66C94100014 X-Stat-Signature: c4eph3ubjwmmc55t6ktc9wrckp8hhdb7 X-HE-Tag: 1728645360-360528 X-HE-Meta: U2FsdGVkX19wHW/+bxrxbkhNaHfKpDEX7JRF1O6pU4aJJKWzcp46MTmTRpzSERcramlcU5e+eb0sFQTmOfKRJBiiqj38cpR2qUH/Q1g0yNI8KisrKNzRgvApnQr4BadVXrkp/0H00UNFhJJgrgeIBUgDfd6rUnhCQfMTnQRaW6LJzZM+VWg0UxkGw5e00OMuP9z/69lu9wHr6h168TlsKZPzSM0Q4J86ppmmEU9AypuGvkvFw3AvVAcYw5yBrPw7eqvfqyqV6BZeF4kxflokEN5pIDLeU5ZK8mDMFzUUbaS4LqOXJBA8RZZJCRaUPrq7pRG6OgxMY/MZsUsmgFw9gB3Z/6dfGAWgWaqfdNYzrkoxR2eI7lGvjv5b+r3GCpflh7OuHPM2H3o0trvnWI8sudFC/vREjcyQKxOuDzUda7oN+AsJUCOt8JuPuqPVZXtjCRaO8IVesTSszn7Z2pcz/+JGYbYtNBpYSZSi2iWmUk86l/uGs/eVhDUghRD7Ju1+EToH+rHvQgMtwI/ZsfAyp6Xb+zzwE+cifdZCIApJM4aBBrudLF7ZaTjSG6efmRz0ek02Gbj0hhjm2EczlqWJSxyYnxg92YAZlPNFgxifQ1a+iP8io5sgs0EXro7C3TH9MZ+fI0xlNpZbDLKrCxHNdKMCOuWAu2JiIOoHhGjjTwBAooURzM5prRfw2Qmm08TPwDdGRDSHLFfx2EyKqsfIOC2x1HTz6z0uygmu3wvqcr8FADrx836kD7NuXB791Mp4NIMCUHs6mAPOw3BxM7zZP899yBja2OGzqUfnVSUSULfTJntgq6c+UQNc1l2F/uUouO38arJLKxLCAK43ZqIA9txmnf1ZpMimCHK5BQjzDwrk9GdGMbVvFcZ+GyMg4aXv6I9HafG5Gbyqmkylm31nt9TOcpoKPrvHETn2cYBmKO9n8mseec8d+fVAC/nyEhhM4TD2nZsWe/DyVFj5OTq j8MGReJT eGeqdqrs0GVcRKEfRUeb2pwavewBp/qqpbMJUQVF6d13dQwW+cUCezUg+LMZ5uAKSztry7eSm/RPSR3BiYW93tOsjnW7XRK//vC3u3NP2ykdOInZVcpZui9zi6NWi+CDTusCY8ysGAtZZzIqABSutEFZcEtS4wtJV1WbL12w/vsby5odGGM5YbygroB5gmV0lT5tyMLbE3xRONN+TBYwZOllKiUb/lBmlrH7Cqdj/6HYoLWWiymap5GYWUsGQxypI0OvQjkxPB+rUkl63FJMRARguylGuJ34OxgzeWROs+v3txmc= 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 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. -- With Best Regards, Andy Shevchenko