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 848DBC76188 for ; Mon, 3 Apr 2023 16:58:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 13D3D6B0071; Mon, 3 Apr 2023 12:58:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0EE586B0074; Mon, 3 Apr 2023 12:58:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF8616B0075; Mon, 3 Apr 2023 12:58:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id DEF6B6B0071 for ; Mon, 3 Apr 2023 12:58:35 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A7AC580BF9 for ; Mon, 3 Apr 2023 16:58:35 +0000 (UTC) X-FDA: 80640688590.23.0945B9A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id D5373140011 for ; Mon, 3 Apr 2023 16:58:33 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=IAzhI9Ww; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680541114; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ghBi7YMH5X5SJy7Ul0V1kMuaWPO39tv1qY31Smab3KM=; b=cvxU7DIBRMas5VPQGnULy4osQjbFyYfL8NmsXBMnp5pW8k3ll519tvyw8QqJog4Ezx/7uc jhZCTrQMiVgiWdZ4/r9TzXKd1hp9ch4x/i70CKbFnvCd7KsdEEsMtD5wOo+6Z0JvddJeTP fqqf41y2Ns8K2GvtEDa5ky8KdN+yvPg= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=IAzhI9Ww; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680541114; a=rsa-sha256; cv=none; b=YFf4KCiIKWLAWib8t93LIbaxVf4wzrJJmbtvUvyjY+OAdeY81DBAMi38kcuzAcyyD+MoaL 7NEOE6dmv6i23woHe9dFbqv6pQslN4q5KTyu0ioJFZ4ImTVFcNYGiDiV23RtVGeafejfZP fBRdq8lX7e3Pul0sRSN7JmQtGK/iGVQ= 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 dfw.source.kernel.org (Postfix) with ESMTPS id C70296221C; Mon, 3 Apr 2023 16:58:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52787C433EF; Mon, 3 Apr 2023 16:58:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680541112; bh=iqxc59ET3lN3lBscGV9OLRH4v6aWLbJznO+AhkK6vA4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=IAzhI9WwctqC0d+GHe9FFn/UcxLKnAH0rIn8xonBB8gz+5nVL29DckeqjaK/qaefq kQjht1tfouiU2hivs3MOsneGFJBAn1S9s+oxZBNAuvd4T2Ohnryw8JXZ8Tyb0q4TDk eh5+Ilg3on+MQIfPETduOI26tIa1N4b1hpenCV5EqWJi/KmcXWds/EVMfr5KIdNNK6 9C8y7EyXPNKB9zjeldz9YrdQFT0UDY5oRKQmjmc9A+WgvEu/zQez2PWHhdDgZDCiKv VKBgTXS+3/YieYDIhsDkr35Bn8TJcA0CWZHDxM4d50ZAbnCmPbw5A4uT1RTEcfhNzK VsWIu1clW1+2g== Date: Mon, 3 Apr 2023 17:58:27 +0100 From: Mark Brown To: "Liam R. Howlett" , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 2/2] regmap: Add maple tree based register cache Message-ID: <6f49fdf0-c373-46f7-89bd-f30f0fb68c15@sirena.org.uk> References: <20230325-regcache-maple-v3-0-23e271f93dc7@kernel.org> <20230325-regcache-maple-v3-2-23e271f93dc7@kernel.org> <20230403154508.qia42tyasj4vhtm5@revolver> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Pz8PLUjRknEnv01J" Content-Disposition: inline In-Reply-To: <20230403154508.qia42tyasj4vhtm5@revolver> X-Cookie: Membership dues are not refundable. X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: D5373140011 X-Stat-Signature: qp9sk4djfkqef35s1f55k8p3uxeeoui4 X-HE-Tag: 1680541113-716156 X-HE-Meta: U2FsdGVkX1/MCoA5VRdbS9fWkfHHapii0403wQbAcDXPkgA6QA5ZPwmUUjobhYLkKDWJp6/NLY8xNfFDMF8yHnWP+7G04MKJ2PzRU7Me7O+nbFosFq4FDmJbOBuurLsjZrM+8vF779tuRmxBzBUbmjjQnK1D39HghTtESEd4B7leLRiZg6wEvxi1sGwM7ppSH3+2iy1qkWift5oK2srhSXr4lu6TdiI0IMnfW6jyB/Ou8a2+SERhWn6kTISKOMHlFduoBtCDmS8GGdUOqWdDPdyGJYkuXwg6zvhHPfWNNfvdXOIxP6KlDYNxwIo572Lv5ilm6QaBkuwo8Lgy8V8X5BwLnPBTIJAzrfNlmIdcJz3nphnqRR+BcFUdnYxJRkO1+rKeRsOS4VdLzofV//h9ebLR2Qpm3+MSs9e39HDdSvh3c1EixjynsjrpM+//UN1AdAu2XbQeu8fukm09m/NX9ktzQqtk7kHWqHjrFk0vO3L+/9Ho4LQ+NusOMg0NyVSxtQAoXp4W7F1ALQE+VLUV/QW9QFyyG3tjl9oYe7ikCaOL5xE3jDLr2bE2fl/d0buQqmCNZrRyYekYzueYy/pJYA651OJGDQUpUZtj9R2jlK5SLKNYEnJAxr93zZcaQ69KELhQyOO+VJC89jbI0Cv71FPCeOHYaZTITeGUDFdUdMUKV27S7+Ty7waFiFgS7kGhd0Bdh4t3QafDhc22BGb8HaZJHBmxB5rGu7ll/miNctfR8qFkiVSVsV7+tjRJ3vjteF8NCih87MA/7pSbEeMjkvC9rwMB2iaxzMctq7KgUSPzsAbP5UWL1lF+z29/NqmNDT0/a8o0zHJ4ilF0MEi5vUnX1OfV2XkVZlKoI4TF8xSCwliH4kqvGYNYkF5I4LB1c4HDdg3rZxinMvs0qCVvkpgOBkfrhcnxWkLbGNxmipPwHePEheTKs/CDwadUpZaZrbqKcIxb9lLN1fZ1N7z 4ZraW+9e PoemsBvMLlTsU/Gn/i3F+R4Tmy9HJ59cmykS+DZlTrDqih2ZHLS8UALHfB4eSM/Id2089sGUomkBomHrDZrDTH66och/BSUCOar8gFc6skIlTO3ddqUhDpT9jX6R51h46iAL9LHcoltEnoDLvbtibkwTwIH1bhQm3vyg8K2joStHDSLUYdzQpPrrEc2TmjRMheXadZyKAfUC2xE9MDk0qkMlXgf2PvE4BsnOW7QO/Ih44O2IADqH0mvsDIB4S5fVVux0SO/ZvMtj42qFdVZYjJ8WtlDdxZsyxPPjDj1fmATiIVVLDDnE/GcPMVuOD4tVdbqgd6wxvFAQa2vnnimvNjCm7rYZK0b36qqm67ZeGGE/jVilwJ83NVyBSLhtDJBL072uFKMj/bMrrdksCFIH/nfuKPykcFWMg9GnQ5FMScsmnQno= 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: --Pz8PLUjRknEnv01J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 03, 2023 at 11:45:08AM -0400, Liam R. Howlett wrote: > * Mark Brown [230329 20:10]: > > The entries stored in the maple tree are arrays of register > > values, with the maple tree keys holding the register addresses. > Why not store the registers to values in the maple tree without the > array? From reading the below code, the maple tree will hold a ranges > (based on registers) pointing to an array which will store the value at > the register offset. Could we just store the value in the maple tree > directly? AFAICT that means that we can't readily get the values back out en masse to do bulk operations on them without doing a bunch of work to check for adjacency and then doing some intermediate marshalling, with cache sync block operations are a noticable win. I'm *hopeful* this might end up working out fast enough to make the cache more viable on faster buses. > > This should work well for a lot of devices, though there's some > > additional areas that could be looked at such as caching the > > last accessed entry like we do for rbtree and trying to minimise > > the maple tree level locking. > In the case of the VMAs, we had a vmacache, which was removed when the > maple tree was added since it wasn't providing any benefit. We lost any > speed increase to cache misses and updating the cache. I don't know > your usecase or if it would result in the same outcome here, but I > thought I'd share what happened in the VMA space. Yeah, I'm hopeful that the maple tree is fast enough that it's not worth it. The main use case is read/modify/write sequences where you hit the same register twice in quick succession. > > + rcu_read_lock(); > > + > > + entry =3D mas_find(&mas, reg); > mas_walk() might be a better interface for this. Ah, that's not very discoverable. mas_find() should possibly be called mas_find_pausable() or something? > > + /* Any adjacent entries to extend/merge? */ > > + mas_set_range(&mas, reg - 1, reg + 1); > > + index =3D reg; > > + last =3D reg; > > + > > + lower =3D mas_find(&mas, reg - 1); > If you just want to check the previous, you can use: > mas_prev(&mas, reg - 1); > This will try the previous entry without rewalking from the top of the > tree and you don't need to mas_set_range() call. Hrm, right - it looks like that doesn't actually apply the constraints so that'd work. The whole specifying constraints for some operations in the mas is a bit confusing. > > + =20 > > + mas_set_range(&mas, index, last); > > + ret =3D mas_store_gfp(&mas, entry, GFP_KERNEL); > You can avoid this walk as well by changing the order of the code > before: > mas_walk(&mas, reg); > if entry... return > mas_next(&mas, reg + 1); > ... > mas_prev(&mas, reg - 1); > ... > This should now be pointing at the location mas_store_gfp() expects: > mas.last =3D last; > ret =3D mas_store_gfp() Don't we need to set mas.index as well? It does feel a bit wrong to be just writing into the mas struct. --Pz8PLUjRknEnv01J Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmQrBbAACgkQJNaLcl1U h9BPMgf/Ui2oTezf7ISr0rf8ZIIqbMcDAA6o/QSvY4WA7elSpDVuS2VXfJTRGPB4 PA6TwsvLLJ5ItxJCTdiR/Z/aNcnq4FlTy59K93kzg1j/0qQoQkE0hmzx7Kzwh3ek xlSfj6IIJsscNHyIskg5D1u0fa7PSZK+2FHJYVv9JB8SALGqZx6P1Do2FJoy+R83 gOeMtCPu7kF9BciL5NBx0Mf6+O8qTvA2UI0MFrrHYODHSGC5LroeSI67rCM+YwW9 6cRSpCyeRpggqLhfaSNHICe0yQwNb8dChVMR+fkbyfCr0NwLQUTjQFLQlctAlHEN ZSLDkyq9Mc0P+NGxgsVkXFsRSTwNVQ== =XOAL -----END PGP SIGNATURE----- --Pz8PLUjRknEnv01J--