Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp1317898rwl; Thu, 5 Jan 2023 11:45:01 -0800 (PST) X-Google-Smtp-Source: AMrXdXvuh0eouzp3HE99IuUG9P68l+/Glb7NghvTjYwzw5D9txAFCWCaKL9I/7So7t/Fn3hg5vYr X-Received: by 2002:a17:906:819:b0:7ad:e67d:f15c with SMTP id e25-20020a170906081900b007ade67df15cmr51770265ejd.48.1672947900912; Thu, 05 Jan 2023 11:45:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672947900; cv=none; d=google.com; s=arc-20160816; b=fS7SfTWdm4FI50DohmeSWQBN86sRB7YdiYCvPSY8w32XdHf14+HeNXIZV22HlFpHN9 k0PXVnXJ/UVBEKGSrfXQAkfQQwxKVScdmvACcPCEikhTfzVPM72m+DmXlHBb2N2Nr1tg eDCwdvy2wOgJHf7lWawnX642y+2iy/QH6I5gDpAAAROqrpzgTbvrmt7r391PVVW1QTz9 lS3NwNqNxZnuY/feTLO12ie28kyBUAb0kt/iRuyq1SdEbkQPbPW7g2HhDY5ENGIbkQ3n g8dauIr5cw5sgFutrqH+/HvBENWeGli3CdizXQuGp+RPfFoymPAtIgcigAiTvrCtC1MX hHxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=+IELmxBW8z1fPFBQY3SLF+cywNZemPcxDQ9U0ufWixU=; b=Khhba0E1Oi3oQVu6MVecRcWCunKEdRTqsMw1GsUMH1ISHz8t0nDkfxw23J/qhi0cd3 L7H0e/afwUGRuo5VXtdeJhxjKO7lTftF1EnHKv/eMkY78Q2rywVkCsD7qQbUACBD3Bh3 a2j3CbEQD86gq5/K4D6LFHfYJpjRz2tscGiTSXij8+IN3k4djyuExLFS1CQn0vjLR0sY QYtMFURZ4RLJrB4LpK8lHgsxLKWV8H+CmzTJDwpQVEH0VkR0/Z39oHY8pqi9BCgWhhl/ VSqAudmHnslhd6itD3VMIYiiy1ajDZ0cTh3UpZw47bTtcnoesRCvHx4siWRho9QEpC7k pUxw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=uTr2lhO6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hb9-20020a170907160900b007c4fb4ee06bsi38176817ejc.534.2023.01.05.11.44.47; Thu, 05 Jan 2023 11:45:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=uTr2lhO6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235730AbjAETf7 (ORCPT + 57 others); Thu, 5 Jan 2023 14:35:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33278 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235164AbjAETex (ORCPT ); Thu, 5 Jan 2023 14:34:53 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E6CC413DDC for ; Thu, 5 Jan 2023 11:32:56 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6D0F7B81BBE for ; Thu, 5 Jan 2023 19:32:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66086C433D2; Thu, 5 Jan 2023 19:32:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1672947174; bh=EgMjUg/SgTSer8lGkKyb8lKAMLgl0roZnntm9yvxsKU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uTr2lhO69gTJMzuNEnGSg2lCfR3saYLkD3ZXYywixKzKKRqxBA01HT6pfqzGl6boF MpYs/Y7ZL7ZJt7BVf/TQIyjEgQ6+7RLdNVloWea7+Rea6KWPyvpCsx0XcnRXa0V+qb 9zQOqHPo6kMxmtyTulPk80tTV8yrdoM9hTmF1CemwIIkyMkdDvqRaQ2bTRignR+273 PvAMOfMWbE5Z2XTwP5X3OpqapXhbLNHWMParTyoS4hRsCrGklqClaPzZ7VQlE5Rkdr CuaQ5bqWL9aWdPB3+YSzHO49GmL17c07RHbEkc/QJ1+QYu8hBrnQgvsETOCnxCY2uG avrzTiCBGx6qg== From: SeongJae Park To: Liam Howlett Cc: "maple-tree@lists.infradead.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Andrew Morton , SeongJae Park , "damon@lists.linux.dev" , kernel test robot Subject: Re: [PATCH v2 26/44] mm/damon: Stop using vma_mas_store() for maple tree store Date: Thu, 5 Jan 2023 19:32:51 +0000 Message-Id: <20230105193251.112393-1-sj@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230105191517.3099082-27-Liam.Howlett@oracle.com> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Liam, On Thu, 5 Jan 2023 19:16:00 +0000 Liam Howlett wrote: > From: "Liam R. Howlett" > > Prepare for the removal of the vma_mas_store() function by open coding > the maple tree store in this test code. But seems this series is not really removing 'vma_mas_store()'. Wouldn't it better to do the preparation and removal together in a same patch series? > Set the range of the maple > state and call the store function directly. > > Cc: SeongJae Park > Cc: damon@lists.linux.dev > Reported-by: kernel test robot > Signed-off-by: Liam R. Howlett > --- > mm/damon/vaddr-test.h | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/mm/damon/vaddr-test.h b/mm/damon/vaddr-test.h > index bce37c487540..41532f7355d0 100644 > --- a/mm/damon/vaddr-test.h > +++ b/mm/damon/vaddr-test.h > @@ -24,8 +24,10 @@ static void __link_vmas(struct maple_tree *mt, struct vm_area_struct *vmas, > return; > > mas_lock(&mas); > - for (i = 0; i < nr_vmas; i++) > - vma_mas_store(&vmas[i], &mas); > + for (i = 0; i < nr_vmas; i++) { > + mas_set_range(&mas, vmas[i].vm_start, vmas[i].vm_end - 1); > + mas_store_gfp(&mas, &vmas[i], GFP_KERNEL); > + } On the latest mm-unstable, vma_mas_store() uses mas_store_prealloc() instead of mas_store_gfp(). Seems the difference would make no problem to this test code in most cases, but could I ask the reason for this change? Also, should we check the return value of mas_store_gfp()? > mas_unlock(&mas); > } > > -- > 2.35.1 Thanks, SJ