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 1E490C433F5 for ; Thu, 2 Dec 2021 20:40:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E5CD6B0072; Thu, 2 Dec 2021 15:40:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 795396B0074; Thu, 2 Dec 2021 15:40:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 636496B0075; Thu, 2 Dec 2021 15:40:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0111.hostedemail.com [216.40.44.111]) by kanga.kvack.org (Postfix) with ESMTP id 524FD6B0072 for ; Thu, 2 Dec 2021 15:40:08 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 11CF18249980 for ; Thu, 2 Dec 2021 20:39:58 +0000 (UTC) X-FDA: 78874020876.08.D62E967 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by imf16.hostedemail.com (Postfix) with ESMTP id 1FED8F00008E for ; Thu, 2 Dec 2021 20:39:56 +0000 (UTC) Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4J4nrS3zKsz4xR7; Fri, 3 Dec 2021 07:39:52 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canb.auug.org.au; s=201702; t=1638477593; bh=rxsPMQUvqs4cE9bEHSMQGUXiGcgarjwQJMa6qhsrQQk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=W+segTKWaXDbDIoF6uqSybHbXs0i8xClofIGo7wH4NH8BDSFyTOi2hh3M4r4t7NCV yyxPhJkcakE6+a5/nKNG7iUS3EXDAUnwB91MGrkFGonk+J2SSgseAyuCE5C+YstTmN YBmIYIwhite5JMHrpkWcZRDj7J0wnvgAvkrtoU6yhYiWsXs84bZzyobX+c14ajBpA+ YW3tZUXUZDJ/dRFcM1ae2PRhQik93fvB2fBslm3VHUh6lBOrakAVZi4ac03S00Xh3n 8EogY5lc2bbrGYBmJIIi7T7iSlahdepmsb5t98RLosn9kd64dZTxZji5TLO37dhS7d yXjD/4jvMor5g== Date: Fri, 3 Dec 2021 07:39:49 +1100 From: Stephen Rothwell To: Vlastimil Babka Cc: Matthew Wilcox , Christoph Lameter , David Rientjes , Joonsoo Kim , Pekka Enberg , Andrew Morton , linux-mm@kvack.org, Linus Torvalds , Robin Murphy Subject: Re: slab tree for next Message-ID: <20211203073949.3d081406@canb.auug.org.au> In-Reply-To: <87d57688-cdcc-07c5-d63d-397806e7ed03@suse.cz> References: <20211201181510.18784-1-vbabka@suse.cz> <3efb8650-e879-8bb4-92a0-c96281b5a6ea@suse.cz> <5387ebfe-03d0-0247-e3ce-97965d5f941c@suse.cz> <87d57688-cdcc-07c5-d63d-397806e7ed03@suse.cz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/=vqtaeNSGS97PICocJacu1B"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 1FED8F00008E X-Stat-Signature: jbxj1mssrrajj3w8bh7x4zfmkg1mp7qy Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=canb.auug.org.au header.s=201702 header.b=W+segTKW; dmarc=none; spf=pass (imf16.hostedemail.com: domain of sfr@canb.auug.org.au designates 150.107.74.76 as permitted sender) smtp.mailfrom=sfr@canb.auug.org.au X-HE-Tag: 1638477596-729931 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: --Sig_/=vqtaeNSGS97PICocJacu1B Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Vlastimil, On Thu, 2 Dec 2021 17:36:45 +0100 Vlastimil Babka wrote: > > On 12/1/21 21:34, Vlastimil Babka wrote: > > On 12/1/21 19:39, Vlastimil Babka wrote: =20 > >> On 12/1/21 19:14, Vlastimil Babka wrote: =20 > >>> Folks from non-slab subsystems are Cc'd only to patches affecting the= m, and > >>> this cover letter. > >>> > >>> Series also available in git, based on 5.16-rc3: > >>> https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/= ?h=3Dslab-struct_slab-v2r2 > >>> > >>> The plan: as my SLUB PREEMPT_RT series in 5.15, I would prefer to go = again with > >>> the git pull request way of eventually merging this, as it's also not= a small > >>> series. I will thus reply to this mail with asking to include my bran= ch in > >>> linux-next. > >>> > >>> As stated in the v1/RFC cover letter, I wouldn't mind to then continu= e with > >>> maintaining a git tree for all slab patches in general. It was appare= ntly > >>> already done that way before, by Pekka: > >>> https://lore.kernel.org/linux-mm/alpine.DEB.2.00.1107221108190.2996@t= iger/ =20 > >>=20 > >> Hi Stephen, > >>=20 > >> Please include a new tree in linux-next: =20 > >=20 > > OK, not yet, please: > > https://lore.kernel.org/all/70fbdc70-6838-0740-43e3-ed20caff47bf@arm.co= m/ > >=20 > > I will reorder the patches so that changes needed in other subsystems > > and the dependent actual removal of slab fields from struct page will be > > ordered last, and only ask for the first, mm/ contained part to be in > > -next. The patches for other subsystems can then be reviewed and picked > > by their maintainers independently, while slab implementations are > > already using struct slab. =20 >=20 > OK, I've did that and removed the iommu commit, and the dependent removal= of > slab-specific struct page fields, until that is resolved. slab > implementatiosn is nevertheless converted to struct slab, and zsmalloc a= nd > bootmem stop using the slab's struct page fields, so the struct page clea= nup > can be finished any time later when iommu is dealt with. >=20 > > =20 > >> git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git slab-ne= xt =20 >=20 > So the 'slab-next' branch is now ready for linux-next, now identical to > branch slab-struct_slab-v3r1, head d395d823b3ae. >=20 > >> i.e. > >> https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?= h=3Dslab-next > >>=20 > >> Which now is identical slab-struct_slab-v2r2 branch [1] > >>=20 > >> When I tried to merge this to next-20211201, there were minor conflict= s with > >> two patches from motm: > >> zsmalloc-move-huge-compressed-obj-from-page-to-zspage.patch > >> mm-memcg-relocate-mod_objcg_mlstate-get_obj_stock-and-put_obj_stock.pa= tch > >>=20 > >> Both appear to be just a change in context. > >>=20 > >> Thanks, > >> Vlastimil > >>=20 > >> [1] https://lore.kernel.org/all/20211201181510.18784-1-vbabka@suse.cz/ > >> =20 > >>> Changes from v1/RFC: > >>> https://lore.kernel.org/all/20211116001628.24216-1-vbabka@suse.cz/ > >>> - Added virt_to_folio() and folio_address() in the new Patch 1. > >>> - Addressed feedback from Andrey Konovalov and Matthew Wilcox (Thanks= !) > >>> - Added Tested-by: Marco Elver for the KFENCE parts (Thanks!) > >>> > >>> Previous version from Matthew Wilcox: > >>> https://lore.kernel.org/all/20211004134650.4031813-1-willy@infradead.= org/ > >>> > >>> LWN coverage of the above: > >>> https://lwn.net/Articles/871982/ > >>> > >>> This is originally an offshoot of the folio work by Matthew. One of t= he more > >>> complex parts of the struct page definition are the parts used by the= slab > >>> allocators. It would be good for the MM in general if struct slab wer= e its own > >>> data type, and it also helps to prevent tail pages from slipping in a= nywhere. > >>> As Matthew requested in his proof of concept series, I have taken ove= r the > >>> development of this series, so it's a mix of patches from him (often = modified > >>> by me) and my own. > >>> > >>> One big difference is the use of coccinelle to perform the relatively= trivial > >>> parts of the conversions automatically and at once, instead of a larg= er number > >>> of smaller incremental reviewable steps. Thanks to Julia Lawall and L= uis > >>> Chamberlain for all their help! > >>> > >>> Another notable difference is (based also on review feedback) I don't= represent > >>> with a struct slab the large kmalloc allocations which are not really= a slab, > >>> but use page allocator directly. When going from an object address to= a struct > >>> slab, the code tests first folio slab flag, and only if it's set it c= onverts to > >>> struct slab. This makes the struct slab type stronger. > >>> > >>> Finally, although Matthew's version didn't use any of the folio work,= the > >>> initial support has been merged meanwhile so my version builds on top= of it > >>> where appropriate. This eliminates some of the redundant compound_hea= d() > >>> being performed e.g. when testing the slab flag. > >>> > >>> To sum up, after this series, struct page fields used by slab allocat= ors are > >>> moved from struct page to a new struct slab, that uses the same physi= cal > >>> storage. The availability of the fields is further distinguished by t= he > >>> selected slab allocator implementation. The advantages include: > >>> > >>> - Similar to folios, if the slab is of order > 0, struct slab always = is > >>> guaranteed to be the head page. Additionally it's guaranteed to be = an actual > >>> slab page, not a large kmalloc. This removes uncertainty and potent= ial for > >>> bugs. > >>> - It's not possible to accidentally use fields of the slab implementa= tion that's > >>> not configured. > >>> - Other subsystems cannot use slab's fields in struct page anymore (s= ome > >>> existing non-slab usages had to be adjusted in this series), so slab > >>> implementations have more freedom in rearranging them in the struct= slab. Added from today. It would be good to see some Reviewed-by/Tested-by tags in these commits ... Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgement of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window.=20 You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and=20 * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. --=20 Cheers, Stephen Rothwell=20 sfr@canb.auug.org.au --Sig_/=vqtaeNSGS97PICocJacu1B Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEENIC96giZ81tWdLgKAVBC80lX0GwFAmGpLxUACgkQAVBC80lX 0Gy0pAf9HuyqsYvHoSl/BSHbS2CQFBBiLhowmmCo5HOM8P1DpiwbyNZBJ3Cyd89J mAgnwdzlQPjmebPs8r5joyWl5i18FO2QvoqW0JAzjNHU8gF3jGt3Zz2qGagRLrec U95IcFtwna87Q5sx008dqD7GvP5CFQLp4axxu2qZh98bajeDo0YuEJHuQSDhD3ej RZRkWA+WfazPQzXdJSEw7dFK/fPvzAWNd8mKLsvvP3L8eFs+Jo2CyCAxHxrHFhui L7RAGDfL7GF2vs6aX3Wl6N5CezxaJ8/xajHQ5LzcNu+diQBmd4c1Vmnwgqq5G5eC 8oAUzFllGotP6lr055D+XLwgvHxvXg== =KeRW -----END PGP SIGNATURE----- --Sig_/=vqtaeNSGS97PICocJacu1B--