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 1D563C0219E for ; Tue, 11 Feb 2025 06:45:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 202A6280008; Tue, 11 Feb 2025 01:45:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B35F280005; Tue, 11 Feb 2025 01:45:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 05644280008; Tue, 11 Feb 2025 01:45:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id DBD5F280005 for ; Tue, 11 Feb 2025 01:45:51 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1C3C31C8D32 for ; Tue, 11 Feb 2025 06:45:51 +0000 (UTC) X-FDA: 83106728502.06.620F98B Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by imf09.hostedemail.com (Postfix) with ESMTP id 33BEE140002 for ; Tue, 11 Feb 2025 06:45:49 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LK9B+ypZ; spf=pass (imf09.hostedemail.com: domain of richard120310@gmail.com designates 209.85.216.43 as permitted sender) smtp.mailfrom=richard120310@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739256349; 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=iCVXdjUT/Nagf6N8WJWobsnGJpE6AKjG5V8TU6Lvk30=; b=Me74uqVZAtbBSLzO0SnUr4YY3o/PkrsxhKZuQ5qS+Peg+loqvX5Y6MoYH7TGll2sTCBh1B n2lx/mbMVp/mx4VerXfMYtRGKnlcUhChvynICk/wNzZiPSgPFHtRGm3ZgJ74qfbsK6ZWre cqPBeMUe6t2HksKcF2qOrjYp50NjuuM= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LK9B+ypZ; spf=pass (imf09.hostedemail.com: domain of richard120310@gmail.com designates 209.85.216.43 as permitted sender) smtp.mailfrom=richard120310@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739256349; a=rsa-sha256; cv=none; b=HmQeEB81rHN9zqoTb4s0QS2bEIxif7GUGzTQtUgB72eCbUWwrJaoqWbqV4EkK7yB/B7m0E EvnmQG4ADQh3KSKu/DF2Wgq/KvfGJXoyIsBZv6ViTcOg3N98A8daPkjU8C1Uja0Pgx7F1a RQlQFQayp4qQj6crtd9Nz1iJoEhmDyo= Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-2fa3fe04dd2so4454959a91.0 for ; Mon, 10 Feb 2025 22:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739256348; x=1739861148; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=iCVXdjUT/Nagf6N8WJWobsnGJpE6AKjG5V8TU6Lvk30=; b=LK9B+ypZ/fetaEkkHMwqdoUlZaB3y8FpilPb0DHZU6ZMvmLOfytZzG0aa9ER39O/3B VJyAGyCfr8RfpgOzF76m/458oQ+swZpQytRd4BMybWZnh9ckN/qTrRmIcojUbw9dO0r4 lEgSU0dbtz+B8zhKm4AHisfdf483oe+QyRhrK7GOrgY8hUFWCxnn0V22WO8i5z2aoKsT 9eC179Q3KziN93zFATD1gs2XEwZByE/0fX5rVrnwx6dI2YeYi9yoPLGhO99MWzcXV1ab ovrBl69Bp4twxpeiQrTyhem03TXMj3lCvdfS5lDLlcWEMZDV8+i7OIB6VJFmabIG50xS 0NBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739256348; x=1739861148; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=iCVXdjUT/Nagf6N8WJWobsnGJpE6AKjG5V8TU6Lvk30=; b=g/isIUeB5iFyfaDDgJBnx4ul5+aKw4C7K71uMUYphBqzDr7g/E5gWac7a8+PrN+llq hUNtHGEu3ts5P16+OM0xeaX0Z7kNCsCsp+0awntoKcikWtmdBmeOZ2Z36f/semCf9tmV nqY0jJDespFuW6VvJNQIgZ7bFV0zBWfYwlSLOP/5iVyMaP5F002q6OgXoiPMkxlHUGQx 0Q61oZPwiFue2aChaeJh6ijPIUiR519Ft6xDuSVyeb7J4KRlQsqevHenPhJBzU0MB3KX 7avpk/TjqAT25HeHa0K69hJfB6q3ugsUZnhLfHoTqdSCy8cu3JzHgph3RVSlgpwquini i2EQ== X-Forwarded-Encrypted: i=1; AJvYcCXnWub/ns096G7+Ppu5cytoaboHW7lPGxKYPaseq4Y7OY0izlBood6tcqO7/qWXtmDx2GU0aCwhJg==@kvack.org X-Gm-Message-State: AOJu0YyMqvJkNlFHIqecogRNMvToOH3mi14EYrvWV623klDG7nYA7RZ1 J8RHSMr3dmKa7mVW9/k3pSx+PpRbmqndWgJTMOpJptDoXvO5Bpgg X-Gm-Gg: ASbGncu+yUcLlAR6YGW8ZzVqLhpFCAZvH24a7ArhKysD6GQ1iNvSqfFFN/WRHV8zH6L PiHb2iChga0nBDTF4liQr3oWBJdvH+Dx4/8NhWqSWHsxhj+dEgKI8Lln6YJT6rt+tLyZMEs+FjB i+j4vOPiNYRKvj/SMMbR//5qpZ+h+i7bwvFygUMvD4ukqu3Ac5qnP9Ib6O3f+3dtKPn2flvIV5w TgFIE8Ue2C+LzOIztCLC2MUpeDxa04F/7DBOBiOFSoqe2l3jUqBP9xA69KkeTmEbg5Gq3rcQZJV WLeb0Wxeh6iFGwyVLKJSugG4NQWyrQ0e X-Google-Smtp-Source: AGHT+IGlOTa9EnjtQSV8dCkcWgXNikv0NjTSbu/EVIRJkA/Mo9cYXJynKQdXVOg66+Rhz4iZLpTBjw== X-Received: by 2002:a17:90b:510e:b0:2ef:67c2:4030 with SMTP id 98e67ed59e1d1-2fa242e5c6amr23132070a91.27.1739256347892; Mon, 10 Feb 2025 22:45:47 -0800 (PST) Received: from vaxr-BM6660-BM6360 ([2001:288:7001:2703:fb40:c00e:5259:b412]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2fa21d230f0sm8192363a91.39.2025.02.10.22.45.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Feb 2025 22:45:47 -0800 (PST) Date: Tue, 11 Feb 2025 14:45:43 +0800 From: I Hsin Cheng To: "Liam R. Howlett" Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, maple-tree@lists.infradead.org, linux-mm@kvack.org, jserv@ccns.ncku.edu.tw, skhan@linuxfoundation.org Subject: Re: [PATCH] maple_tree: Remove redundant mte_to_node() in mte_dead_node() Message-ID: References: <20250210083526.252955-1-richard120310@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: fyrquzf9ijt873t64s4sh899bb9e7sks X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 33BEE140002 X-HE-Tag: 1739256349-12282 X-HE-Meta: U2FsdGVkX181OQbIEMCFayKEhbRca6Q6C+J/qiLIDOuijGQuVb6rYpFQNI+NqUX1wPjm85L0B7U1zSXHt9M0QX2Nqg44IOZR75rSzPL/pj5N99gwir7FqIcFpuZ1+bfyObIXHEwNXmdEMavdAxWyrhc+FS43gBj4YevrEUxjvpYGgkDhDTKD5Macgd7NPD1UtmZPeD+d1b/gYPt6rqfFehbmM8x1KG2Kw4ktcSiaWr1tmbhdFKRgD2ErYqtMbBXuDp/M2g+9YZmih+BSigA47oYAI9S4fTSMQgRIFMp86X+Zexm7y0IHh9Mk5yiR9h8VzvtXUxnjMdXqa6w0UwBalrqc78t/9G7jypQi2Jt/ep0is0M1BAGqI8Ng6kujppUm+hLROsDI2I5BRZzljF+ZZFxQRdxuddpllsfJUQPYg8GyhHc/UlNUOu507KRF9x+Ly69ZuWNYm27AmiTHC3uu/QzuCgF+VjlVA0RmVxSkeqMncWgtHIJ4jbonJMsZPnXA+ZWSWvmDF3FzyuXPtFzmnIoxmXghHwt93El3biHm3qusGKw8LjgGsxsQWdyQ4MKcqEtQCd8tp7YsnsDyBRYBL5ETF/cxbKDPxsFb+f1qH1vr1yo+HIK4UJrNx2rwrdtTQqxC/YEnjfNSogHdfRxF8nv4q2QrrLnghrYM5jsPNrMinknHZL9FahyxwyDtA3QDb8WrASF+BZpoHdv/8wOfI8tXEKGdqr8YHOPBfZmlbyvEEe158mD4bUKexyZMkCOeNz6uT44IyAxYruNsA6/WxN5qZ0PCAkS+nhjg2cw6y1ltwUwEdPawiG8e5tloTQ2V2J4Wy53ZNqnkMvkru2b7FV3AzJERbYt1I6miw/0dgevvAF4ALsMqRcy3H/HtFoq2EX5aeRr8q320kRFX2D1ZMWcvqAdjOiGm6swvtHke4go3p+AxvTtxpFjahGFFWtUpLy6Hg/UxiMLQEPcaD9Q 3BynaOlw djGHJjthcWY2Vsq8atHCnaqDoH8L6XVAqzwO/niXV0CuCLTwEuFt49ed1BF2wcx32tguonDhCvxhHz53FwtapTnGYfa9s2u3ReeBRvDBkPwl5Ff2dPKHZTaHbbziXilUu4neFasBPI7pSrokrv2BcVtuJaf6WDO+YgvtwPzU01W7URtS1dqMwR544usJxV2Vep2rHt6VhTll52nS9WzAWRMiQBp4ObhXDT9k/alK64eZNLMwDeicxa6PD1VSl++9cstQ6xefBeeL8wsN1fg6MTIvE2m8R9MAlW65IrrfxmQVLKkzL3Hp9rJrPpu6reN3Ye4TsvlBOqzz4WbGlfGEFG8TqEPG3yrpcyGsg+Q5R5umKxaQzkBtn2/dJUubhYl0sbuZ2CDlcLPkDNqnuIGFcABNb2+cWxOsqcu0aVcx7mNoepimvyCKiAlyIkWTF8QEZraq5gqGRZQDJIy1vr4q6WrRZoPSYI8Y3D8eR36lgpF6duZVN6SS3gftABNqzBnkZOsX1 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000212, 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 Mon, Feb 10, 2025 at 09:51:42AM -0500, Liam R. Howlett wrote: > * I Hsin Cheng [250210 03:35]: > > > In mte_dead_node(), it already assign "node" as "mte_to_node(enode)" in > > the first place, calling "mte_parent(enode)" will result in the same > > "mte_to_node(enode)" again which is redundant. > > This is a very confusing way of saying "avoid calling mte_to_node() in > the mte_parent() call by using the ma_dead_node() instead." > > In fact, the subject is wrong as well, since the mte_to_node() was > removed from the call path of mte_dead_node(), and not the function > itself. > > > > > Refactor mte_dead_node() and utilize ma_dead_node() to perform the > > parent check without the redundant "mte_to_node()". > > > > Signed-off-by: I Hsin Cheng > > The code looks right, but the subject and change log are not. Please > respin the patch, something like this: > > maple_tree: Use ma_dead_node() in mte_dead_node() > > Using ma_dead_node() in mte_dead_node() avoids decoding the maple enode > for a second time to find the parent. > > Feel free to change it as you'd like, but I couldn't follow what you > meant. > > > --- > > lib/maple_tree.c | 7 ++----- > > 1 file changed, 2 insertions(+), 5 deletions(-) > > > > diff --git a/lib/maple_tree.c b/lib/maple_tree.c > > index f7153ade1be5..362f85c62678 100644 > > --- a/lib/maple_tree.c > > +++ b/lib/maple_tree.c > > @@ -584,13 +584,10 @@ static __always_inline bool ma_dead_node(const struct maple_node *node) > > */ > > static __always_inline bool mte_dead_node(const struct maple_enode *enode) > > { > > - struct maple_node *parent, *node; > > + struct maple_node *node; > > > > node = mte_to_node(enode); > > - /* Do not reorder reads from the node prior to the parent check */ > > - smp_rmb(); > > - parent = mte_parent(enode); > > - return (parent == node); > > + return ma_dead_node(node); > > } > > > > /* > > -- > > 2.43.0 > > Hello Liam, Thanks for your kindly review! > In fact, the subject is wrong as well, since the mte_to_node() was > removed from the call path of mte_dead_node(), and not the function > itself. I see, I'll rephrase the whole commit and send a new patch later, what I wrote is indeed too confusing. Thank you. Best regards, I Hsin Cheng