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 E29C9CFD31D for ; Fri, 11 Oct 2024 10:49:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6BDDB6B00A9; Fri, 11 Oct 2024 06:49:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 66E566B00AA; Fri, 11 Oct 2024 06:49:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 535776B00AD; Fri, 11 Oct 2024 06:49:38 -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 35E886B00A9 for ; Fri, 11 Oct 2024 06:49:38 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D752A120712 for ; Fri, 11 Oct 2024 10:49:33 +0000 (UTC) X-FDA: 82661000352.23.50C4FC7 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) by imf22.hostedemail.com (Postfix) with ESMTP id 85099C0011 for ; Fri, 11 Oct 2024 10:49:32 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=EnmWnZoO; spf=none (imf22.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 192.198.163.17) 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=1728643636; 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=1m3NjE7ZiZR9TG4KhWSNl9VWxRUQFfKZWafhxSJ+iHo=; b=Ya3uoO5/mLsjjJ1zllltPDmIfzZyxuq8YFFmJJdZGo6FWPiE0hF7vO20733odDiGS7qQ15 UPbB+2wp4EP7RbrdYDqiOC7D2V7aWY3Stb+3Nxp8pXGZFQgugDV9LqwGiUXvnFM54GewLw b8BSBmJXTd6Sf7MXqT7Gj5qfHAiVPsA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728643636; a=rsa-sha256; cv=none; b=Q3YuSc9MAjBKks8+fnHWvaqQpgrYMP9yJnmhjYcXoa9xx2w3cgQ8Gt37E+d3Edl4kc07sW 7pOaAcREYNf3425bFfctH/IkZJtcAJK4z1XXivrdmd+kpwp7FYXvralpyEKGALfmUvFTPy JfWomHHpDHayTs3RlrHsS5NIb3rkSlY= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=EnmWnZoO; spf=none (imf22.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 192.198.163.17) 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=1728643775; x=1760179775; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=XH9y2E5yHPSSbBGvg6K2K0apjNjCYkkwGjaiDudoz1U=; b=EnmWnZoOwY8pHco/LXjO6DmxjyZycEZkONgPzjptbel2GnTD4RG25rrX 9t50EoDMiALzGzJHI+qbE5r8NILR0DQol3c9dvRo5ueJwte4q1fkj8eC8 pw8Eu+k56gp5JlReJO94agQvwX8QEIBNtCYjser8K0fzh5je4m1OVaRew iSZZ/mK0aqCTHEVjjoUiowufZd4wCYra/ZypszifEcXG0TucvrzMW7IAH YZ8S82a36KqKNu1j2l1s0pMAdGh4QyYhkkBJFacWcbO04xkV8HeXlUaa1 8tRTV9HNYHFreQezYLtc5i5RBG9JjBwdFDBcPLPLs5Sdjs36rWxi3x/vc Q==; X-CSE-ConnectionGUID: W/bm+kyTS6i1eBwBAXpcWg== X-CSE-MsgGUID: I5sd4RmgSeqBgEGsZvi/cw== X-IronPort-AV: E=McAfee;i="6700,10204,11221"; a="27909894" X-IronPort-AV: E=Sophos;i="6.11,195,1725346800"; d="scan'208";a="27909894" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Oct 2024 03:49:33 -0700 X-CSE-ConnectionGUID: 7/ZcGODLQUWBwWhh7JtSpA== X-CSE-MsgGUID: Kg5MiDyFRtSq+ak0B7s8Dg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,195,1725346800"; d="scan'208";a="76984507" Received: from smile.fi.intel.com ([10.237.72.154]) by fmviesa008.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Oct 2024 03:49:30 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.98) (envelope-from ) id 1szDD5-00000001reQ-1m08; Fri, 11 Oct 2024 13:49:27 +0300 Date: Fri, 11 Oct 2024 13:49:27 +0300 From: Andy Shevchenko To: "Huang, Ying" Cc: David Hildenbrand , 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: <87set3a1nm.fsf@yhuang6-desk2.ccr.corp.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Stat-Signature: s1kbd6taxu3cqg4h4ueebo4nm6etj18k X-Rspamd-Queue-Id: 85099C0011 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1728643772-963723 X-HE-Meta: U2FsdGVkX18BcxtvXY9tBD8gbap79MhVGEkWl+1zjf2EMLrt42D4X+CZ4FbbvH8m1ElTDT3q7KK1XFrfWgEDM1oWaGf+/z7iVnho9ZEG2s1LbOoHZKzAsuIFowXcVJRYP1kM4bZCEv8nYHLd+Bkmng2wU9MmmIXJfhUQBoteSu/zpes07DRc2hSDcr0WIemI/qVZybyze6DB0UZKs2Jv7LZbJE1JDfqbdXJ89KVxeJsspFZ66tkLVIyxs1yl39Ib4TTL9r915dsNNyHNYOacSZzASRPSXqos2VRMZtUcXOtPmfxy/4zyUU2nbwt77o5KuORJCzsuTeZyxXygfWJLc/7FybS13k+v43umcazxVVFMRdL5dCDJa0uPGVefHLgs4bD6GRdiY68liO2QUUlcuANlciGaAvY0e3D3jp9N0zJ2HAgS6uSTWcxzEgkHnlY3WtsJzIURWni4R5ImDimK8iQepmPvuj06KPX5SAS1PNgX38A3UbUyaDqbSiznWNNH1+MbxuBhCgEcwElC9dsQ862y7/l5BKZSBQY06JMqcE8YtdQNl3ud/hFNWngJBzwVaPOiEksiEhnPVWLliE8xjyMmTNiZGwRHRv7DJIPpU5QT8AHdjuPrwX27xVgUkRpMsSXjw7U1vvnECJ8Fp4feLWewAqqz+14QE0ZSF0Av3C0sxVr2LhOYyE4cyB2hvTiSIhvO9CHjeaaJ5ihFY41fqmTjAvdlJQHmUK7zO+vXwiZfzAyfOPIXp4v783M7Zp+1V2aDfLsDQfPFteOg/BYmI9PfpneKfsnJmCnetZxt0TEh4deejv5rPmeElcXIw4AWruztaEYZ/kuHvYPTZ2G3TLMv5uV3nMJVOq2lmiq8yElDejzTSXx+HbvbMj3z665FBwsJQ1XKI4fPDYGOMxg1EHYEJwTsZro9+kbVJzRt4/McE0HhAp1BVauwX2LMNy/00nLeVEUxBRfsDnqDQbc biedkeiU 0aHLd64/i5ZNbludtmMLn7yJNZStx0VdGMVEs7LTlmCofNMoXQdIbMO6HotYPTcS89y5hTsxZBPaVJoa/aIb0JtvGLxFccX5Q8anM6HDk+LdjqpSO+Favyqg6DfVH0BlKFIvmFzofe3XwFLvcWD5Yl6z9FYy/AnYbwz++FRVE9K9fvubXdrmPiCHy+ROmBe6a7gOPWYqek/NXQ0Lwrtot6hofnRljJAF2mvRFshlysavDjvLZDDd7C+UvaTs8QVaAqLvFuRfRDMiv7/DTexqi//w0hof5bv9TBl6BvquYsBd/B1A= 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 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). > > XXX TBD > > > > Or do you think this should not only be "improved" for the __region_intersects() use case > > but for all for_each_resource() users? I cannot tell easily. > > I prefer to make for_each_resource() to traverse only descendant > resource tree of "_root". This helps code reusing and make the > interface easier to be understood. The difficulty lies in twice > evaluation as above. -- With Best Regards, Andy Shevchenko