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 C8EBECD484A for ; Wed, 4 Sep 2024 14:53:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5CD136B0124; Wed, 4 Sep 2024 10:53:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 57F106B0123; Wed, 4 Sep 2024 10:53:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F72B6B0124; Wed, 4 Sep 2024 10:53:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 1F7E36B011F for ; Wed, 4 Sep 2024 10:53:11 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 99035A15D1 for ; Wed, 4 Sep 2024 14:53:10 +0000 (UTC) X-FDA: 82527348540.27.B30A8DE Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf15.hostedemail.com (Postfix) with ESMTP id 90746A002A for ; Wed, 4 Sep 2024 14:53:08 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=SghkQNnB; spf=pass (imf15.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=richard.weiyang@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=1725461493; h=from:from:sender:reply-to: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=3AX/6CfIEy4GHg38VWWC36r1wGJ3D7xM94l+yZpA62I=; b=buf830qOwvdthbOto6rtEYhIUOdfI6LvDBnFViHb79vN5TeLoBmwzKkFezxEwYqKocJ7/8 fSDREw40tBnSoR1+92vzlI5cBygVasuP5S2W3J/w+ageZ0ZRMnfvSGXC5EOBYVzq3KE7I1 P9x5J8UdkYsQAxXpEYP9rqimHlQin2E= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725461493; a=rsa-sha256; cv=none; b=OgZzV1tUzubLiE4SxXFFBYVVI1uvjMXabf81MQhMc2y3O+fLfYmkFNLFjMWTHGx1R5KvCB lMT6M4MU+lbrBx29ucjdE35rSDh7w/Cc8FO1W+25qtXjxLLaW/z77x5d8buYXRaMrdEfsT 1rLWue/AHaXwfziyHJtof5EgHlFtxWU= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=SghkQNnB; spf=pass (imf15.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-5c24ebaa427so1321295a12.1 for ; Wed, 04 Sep 2024 07:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725461587; x=1726066387; darn=kvack.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=3AX/6CfIEy4GHg38VWWC36r1wGJ3D7xM94l+yZpA62I=; b=SghkQNnBi+YrLiKfarSxJoy07UEUqfl6XaiesO0avtm7hCcLQ0XQhhmDjAYJO7xph+ sm8yxmw9aFPIi2oAhpxu0g2N08Dm4N30gbekHDlm1Ss/zcNROO/5u6oKiSJDFK9Gwe5o JNIMjRNkibIB8s6oVHtcuj0LIhGPCRf6X+5QQdyIAdhTYVRmt3Fh3hBlBgJM4ynTfJIe 01BCulGh4emUWiGEcixpLm0RLaL638+Uc4DfFcvr94amHSQvvAB+mBZJJYAtD/dMzcr3 7m614jr2b5kgqVvQNggmKPEg2A3yslqdQlmxzQPnc9VZi89I+OgZ9k8i0fE0FdHMsARV lDBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725461587; x=1726066387; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=3AX/6CfIEy4GHg38VWWC36r1wGJ3D7xM94l+yZpA62I=; b=mCu/PcEQ1Ej5IWb1tWsZ5EQXEC4pqgz9DQydJz8hFTHGlL+tfkzJvjgKuJwCsXPOZf GxtMrds6I2gL3zLnsdwqQ5qvkJZm9YPVj9Jm/ZHpNSIdhl4AVxcGSXiKUe3SJ0iGrFIS tGV92cxwDRWSt1P5MCv2YQLHMi9DrTlBo0mo6CCbG3tHgUHazRja56PFZ5gJGSOoETs9 Z5xXWu+sdJCcjGTLzL9SbE5yJ7Ue2fO01RYnrH4eV0qwq2tVpmOtx+9xIaeO95ghzZ6B IId0w62PGkCvyLLSMxLeLrWP9IJJNPEnuLLQN2r6zMBPz7e5JsA+VCUvUiz+MCygtqen E6yw== X-Forwarded-Encrypted: i=1; AJvYcCUjdQ6rTzJk9407ZRHNmmquzyiRE5tcieqohygKON2XmwKUWpikTkHSZbSzn4hU6MQCtcNX+42mOg==@kvack.org X-Gm-Message-State: AOJu0YxZR7dDEp16AY5awp0PD8jiod08dYCDALE3ZDzyaU0SmDlwe/Jw rHXKdtJ4N09Gd4T7sPbqKbP1ybtKHXOqvicn/5TTsGuhAcsDXyOU X-Google-Smtp-Source: AGHT+IFV/MtQW/4Vfs23HwW8OJ5Q9WB2UmLxhEWmHP7wHCjcB1e73jQPUSd57QgbsjYRuWgrdEtY4g== X-Received: by 2002:a05:6402:1d54:b0:5c2:5248:a929 with SMTP id 4fb4d7f45d1cf-5c3c1f7de77mr2763153a12.7.1725461586690; Wed, 04 Sep 2024 07:53:06 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5c3cc54fbe5sm17779a12.34.2024.09.04.07.53.05 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 04 Sep 2024 07:53:06 -0700 (PDT) Date: Wed, 4 Sep 2024 14:53:05 +0000 From: Wei Yang To: "Liam R. Howlett" Cc: richard.weiyang@gmail.com, akpm@linux-foundation.org, maple-tree@lists.infradead.org, linux-mm@kvack.org Subject: Re: [PATCH 1/3] maple_tree: use ma_data_end() in mas_data_end() Message-ID: <20240904145305.dq7jolrwd6fp6dmf@master> Reply-To: Wei Yang References: <20240831001053.4751-1-richard.weiyang@gmail.com> <20240904001525.5zshbivv7op4ana7@master> <20240904075819.5vgnelkxxj7myyn4@master> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240904075819.5vgnelkxxj7myyn4@master> User-Agent: NeoMutt/20170113 (1.7.2) X-Rspamd-Queue-Id: 90746A002A X-Stat-Signature: hpfq4daa4rbxb8nu4d3howkymfu5zpoe X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1725461588-230475 X-HE-Meta: U2FsdGVkX1/MdWLmeYlTtrECYFnLQ8NWZk+WVgumGzkDCfP2LHWiWEWWifqURi8yvRKL9IV3I7w10MDpgQrwxFq4OwYQJRXMJBKvKOlC7yJALdwey0FuSLi5Ninb3cl4tMa6ypmXzGlivGf4UKcMhGlb2pwzMH8b3JT5Buwy2Cts8omunMAUH1WDP/ZcTj4NDhibeC4E2j3N1sKI0wQj4octswpK6zLxns/hL5OcgTa43ZMCq3PUCKuMqRdCHsjipxwk629w754oY4vtRul3zPKUDL/p/ZzSMZFJ9AzjTKIzfoR2oouGqdRSaAxYKJMh/MnN2xr4YHnTKLhJVghw5YR7Px0MiGzKRWpUDaZBw/pRFIuadkvnxTzgzXvRqzj1MpYCc7/ExqZOvS8e0TY8jgXTPCt+XlH0MQ2jubxIw4Pnd9S13wOTJyhcmDqHdDGlWabUdR5ejGKa92IQ7paoBVQgE4t6nf16PEIAFz73E888TO9okXgerTO0mN0lQxo77muRzCdLcBIiV5LauzA+I++a2G0KkBZR01RmMCi6jTHpHEnv19wHUrD8r3Cj26fxzWtrphOUVsGVfDiD1Q6sQFY8YetPkgiyuZkmFAi029OyV/oGr6fjLB1trsyxZlXubclhFtINAcVSZM3cV00A0/9oNtb8NgCcSldsGwRhyobGM53gFK1K/mpxlmxvT8Z+R9TrJm5x5yhbGYnL9qmAg9I1BDqDlrEpizkHOU/LLBKR7fHx+1GfdgO9GwTK7IFWwk7DY02+0ReCfOu2MPB5CjZ0xtYsh55zqlnCHCXssGrMLSQGnQvT8657/SUbqfsb8jodR/zL+rrmn9aJCVp1JkAUqxc4l12MnbdBY14SCcaOE5IbKZFliZbwh4gFKqlG61XMicj2z/kl7G339euLHKVJRvCQgtXZdZCrObkafwkfQ9hDtooJ66M976sEi+NXF70bwhoyooA8KHyhoso aEnaAeMW 9/0Rq388vi3o+8LqNVA29igOaxGO3oV7CfrpzcZQlHHdXGTaIowqEsmxHPAy7P84WVUBI+W94Bf5tCTddccEMo3nVW2mnKgCqxVu3GBqyBD6ZWBonfuFdUrRQG+fVfCO+a4Lm/Si1+3yU+3mOWPyyqnuatcq5bdokVCKP8OCft2keIiuAo3tmFw5xD1FhDeokChAdPG15/AGVqzNRZiNYKGdcpY9lfoJ2cQ3KJIn8xME9fu278y5vcv4mQz8usm7JjWD778824XJ0BZ9aeyYbC3vs+cbHUyO686RyNAj64BpFv+k34bPve73RYp8gKXAljd6kwOp3Xgriwm2HXwTskQINNEFr1Zw4DBexUg4mZYou3aDVHkS2ZeSgYAIl9JuE1vMTd5BPZbxrtuAO1SH9wdLqh9GU+bXS1NmAU4auM9AaRwVMm4OsnCPqH30nWfwtYNgBFb+dH1+jYGTT6l0GzpC8OlPfIs0o+L3RdbvdMxCyNAxenqaw5d04X5Odf4ySTxE7T5yavVzXiYTc6cblk+XuGYnuReMsOWItQrwJc/JiuEyduxD1sOVOFtlKAuS7S7C74XGyDye+BKCRBOpsIJqLp8EWnuA8vVKBvA7G/1StswhN82nELQYKnLC4hzZdye7HdHldgng8ol0Nxa7p1rDFwBPv8X4n2SUD X-Bogosity: Ham, tests=bogofilter, spamicity=0.000286, 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, Sep 04, 2024 at 07:58:19AM +0000, Wei Yang wrote: [...] >>It is only changing code for the sake of changing code. And it looks >>like it will be slower, or the same speed if we are lucky. I have to >>take time to verify things aren't slower or add subtle issues (maybe an >>RCU race) because the code looked similar. It's just not worth it. >> > >I am trying to make the code more easy to read, but seems not helping. > >BTW, I found in mas_update_gap(), if (p_gap != max_gap), we would access >the first parent, parent's type and its gap twice. Once in mas_update_gap() >and once in mas_parent_gap(). > >Do you think it worth a change to reduce one? > Liam, I am trying to understand what kind code change you don't like. Is the following change worth? diff --git a/lib/maple_tree.c b/lib/maple_tree.c index 2b310dd3addf..e331d086eb7c 100644 --- a/lib/maple_tree.c +++ b/lib/maple_tree.c @@ -1595,32 +1595,33 @@ static inline unsigned long mas_max_gap(struct ma_state *mas) /* * mas_parent_gap() - Set the parent gap and any gaps above, as needed * @mas: The maple state - * @offset: The gap offset in the parent to set * @new: The new gap value. * * Set the parent gap then continue to set the gap upwards, using the metadata * of the parent to see if it is necessary to check the node above. */ -static inline void mas_parent_gap(struct ma_state *mas, unsigned char offset, - unsigned long new) +static inline void mas_parent_gap(struct ma_state *mas, unsigned long new) { unsigned long meta_gap = 0; struct maple_node *pnode; - struct maple_enode *penode; + struct maple_enode *enode = mas->node; unsigned long *pgaps; - unsigned char meta_offset; + unsigned char offset, meta_offset; enum maple_type pmt; - pnode = mte_parent(mas->node); - pmt = mas_parent_type(mas, mas->node); - penode = mt_mk_node(pnode, pmt); +ascend: + pnode = mte_parent(enode); + pmt = mas_parent_type(mas, enode); + offset = mte_parent_slot(enode); pgaps = ma_gaps(pnode, pmt); -ascend: MAS_BUG_ON(mas, pmt != maple_arange_64); meta_offset = ma_meta_gap(pnode); meta_gap = pgaps[meta_offset]; + if (pgaps[offset] == new) + return; + pgaps[offset] = new; if (meta_gap == new) @@ -1640,11 +1641,7 @@ static inline void mas_parent_gap(struct ma_state *mas, unsigned char offset, return; /* Go to the parent node. */ - pnode = mte_parent(penode); - pmt = mas_parent_type(mas, penode); - pgaps = ma_gaps(pnode, pmt); - offset = mte_parent_slot(penode); - penode = mt_mk_node(pnode, pmt); + enode = mt_mk_node(pnode, pmt); goto ascend; } @@ -1654,24 +1651,13 @@ static inline void mas_parent_gap(struct ma_state *mas, unsigned char offset, */ static inline void mas_update_gap(struct ma_state *mas) { - unsigned char pslot; - unsigned long p_gap; - unsigned long max_gap; - if (!mt_is_alloc(mas->tree)) return; if (mte_is_root(mas->node)) return; - max_gap = mas_max_gap(mas); - - pslot = mte_parent_slot(mas->node); - p_gap = ma_gaps(mte_parent(mas->node), - mas_parent_type(mas, mas->node))[pslot]; - - if (p_gap != max_gap) - mas_parent_gap(mas, pslot, max_gap); + mas_parent_gap(mas, mas_max_gap(mas)); } /* -- 2.34.1 -- Wei Yang Help you, Help me