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 X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AD6DEC352A2 for ; Wed, 5 Feb 2020 18:43:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7294B214AF for ; Wed, 5 Feb 2020 18:43:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="PKnya2jD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7294B214AF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 26F2D6B00BD; Wed, 5 Feb 2020 13:43:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F8A46B00BE; Wed, 5 Feb 2020 13:43:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C0C46B00BF; Wed, 5 Feb 2020 13:43:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0049.hostedemail.com [216.40.44.49]) by kanga.kvack.org (Postfix) with ESMTP id E5B956B00BD for ; Wed, 5 Feb 2020 13:43:46 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 95BD52473 for ; Wed, 5 Feb 2020 18:43:46 +0000 (UTC) X-FDA: 76456947252.13.beam11_20e3cb6ce5d3a X-HE-Tag: beam11_20e3cb6ce5d3a X-Filterd-Recvd-Size: 5774 Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Wed, 5 Feb 2020 18:43:45 +0000 (UTC) Received: by mail-qt1-f194.google.com with SMTP id d18so2357732qtj.10 for ; Wed, 05 Feb 2020 10:43:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=wUGSc9NsfhLrJXw9g/4Cpl0NU6/CjpbaN2Q3d5tWnZs=; b=PKnya2jDW985US1MTRKHQm6dmuXL/UZOcOd1v0E1TTq5EoyCwgDdlMqsrSUWEkewea apf9GjnTSZVUJRmkrNUtAxr0pvjBBn23k9VtcuRN6lgPo5OPfBzQimfebe+K/cgh1qpk ZuCSOcZ1VWhWabaUtwk9/ioupfoDxXRwPcc1DL8DTv+q8jkj0lSUCOznWLvp7S9SN2Ut 5gRBdphsxNcNcUOkFDJFCKe3cmPexCsg2j6SFNx6KegTgFeCBen6j8/AP1NvAGOteU0n 0xu6GmAUjVrlGtakoMLpibu6pqgKYcp0ENDw9mkh2P0bl/FiC7/D7pXUKrWDYwZUpyyQ l8Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=wUGSc9NsfhLrJXw9g/4Cpl0NU6/CjpbaN2Q3d5tWnZs=; b=PkHc64cjKAn4R4+CmEuzzwykhfVsbtz4/L1Blto9H02iXhWbgKl3wpkiRWjpcVLNVJ TWACN5G7QRYC4YIeR9VaZS0RMiZPHSyZy7M2EIQ/MjC9504YfyeN+8bs/y8cfI4Ye7gm V86TeCYHECQyCXGeCV8pcq4KhWlYPlqzk2BUON9rrXqNre0lkBlnvTW9cWuAhmK4noSU o8uZ7wmhzo14rNxX+xdTlNSIshz7r+WGMAgPydvvJ9+HHEwScWceBkgwxVUx7bKqyy6q VaRLhcxiVeuJWQNrDv6qx+Prpx6Mbww7NSmPCcP2c5YVeSet20WtT9Qkt1LzlgXDe2mH JxDA== X-Gm-Message-State: APjAAAWvSCVU1g9BlVTmJuJv9w3w8jcNec4CI3gefGCfo4IoUJQqyTYZ MiN5iLArx2yHhK1PQezLZRhp0g== X-Google-Smtp-Source: APXvYqwQzpvt9yeTkF8L2SKyrbhpdQshqja8XbcgDwPH/vQuEzBmocOOuFllhyb3PAnFDLyK5Sa1VA== X-Received: by 2002:ac8:4a95:: with SMTP id l21mr35222430qtq.353.1580928225322; Wed, 05 Feb 2020 10:43:45 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-68-57-212.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.57.212]) by smtp.gmail.com with ESMTPSA id n20sm243053qkk.54.2020.02.05.10.43.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 05 Feb 2020 10:43:44 -0800 (PST) Received: from jgg by mlx.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1izPeK-0003sV-A7; Wed, 05 Feb 2020 14:43:44 -0400 Date: Wed, 5 Feb 2020 14:43:44 -0400 From: Jason Gunthorpe To: Jan Kara Cc: Matthew Wilcox , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 8/8] xarray: Don't clear marks in xas_store() Message-ID: <20200205184344.GB28298@ziepe.ca> References: <20200204142514.15826-1-jack@suse.cz> <20200204142514.15826-9-jack@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200204142514.15826-9-jack@suse.cz> User-Agent: Mutt/1.9.4 (2018-02-28) 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: On Tue, Feb 04, 2020 at 03:25:14PM +0100, Jan Kara wrote: > When storing NULL in xarray, xas_store() has been clearing all marks > because it could otherwise confuse xas_for_each_marked(). That is > however no longer true and no current user relies on this behavior. > Furthermore it seems as a cleaner API to not do clearing behind caller's > back in case we store NULL. > > This provides a nice boost to truncate numbers due to saving unnecessary > tag initialization when clearing shadow entries. Sample benchmark > showing time to truncate 128 files 1GB each on machine with 64GB of RAM > (so about half of entries are shadow entries): > > AVG STDDEV > Vanilla 4.825s 0.036 > Patched 4.516s 0.014 > > So we can see about 6% reduction in overall truncate time. > > Signed-off-by: Jan Kara > lib/xarray.c | 9 --------- > 1 file changed, 9 deletions(-) > > diff --git a/lib/xarray.c b/lib/xarray.c > index 4e32497c51bd..f165e83652f1 100644 > +++ b/lib/xarray.c > @@ -799,17 +799,8 @@ void *xas_store(struct xa_state *xas, void *entry) > if (xas->xa_sibs) > xas_squash_marks(xas); > } > - if (!entry) > - xas_init_marks(xas); > > for (;;) { > - /* > - * Must clear the marks before setting the entry to NULL, > - * otherwise xas_for_each_marked may find a NULL entry and > - * stop early. rcu_assign_pointer contains a release barrier > - * so the mark clearing will appear to happen before the > - * entry is set to NULL. > - */ > rcu_assign_pointer(*slot, entry); The above removed comment doesn't sound right (the release is paired with READ_ONCE, which is only an acquire for data dependent accesses), is this a reflection of the original bug in this thread? How is RCU mark reading used anyhow? There is no guarenteed ordering of the mark and the value, so nothing iterating under RCU over marks can rely on the marks being accurate. Are the algorithms using this tolerant of that, or provide some kind of external locking? This series looks good to me, and does seem to be an improvement. Actually the clearing of marks by xa_store(, NULL) is creating a very subtle bug in drivers/infiniband/core/device.c :( Can you add a Fixes line too: ib_set_client_data() is assuming the marks for the entry will not change, but if the caller passed in NULL they get wrongly reset, and three call sites pass in NULL: drivers/infiniband/ulp/srpt/ib_srpt.c net/rds/ib.c net/smc/smc_ib.c Fixes: 0df91bb67334 ("RDMA/devices: Use xarray to store the client_data") Thanks, Jason