From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BAD513AFAFA for ; Thu, 2 Jul 2026 10:48:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782989318; cv=none; b=pgAbJX/zNOa/MHY7/iOWEE2DUjHcPYsSEmvlmCt7vFdGAq+WvmoIRaVSs8/uhg3iGz6qsfdZZYBBQ3ZFDbNFOsmn86j3kgxsrtQaFgksZIq/SlB8xL7gA8Bw0pd3L6Ije30LKACm5PtgDuVWnzgDqoToPTwfecXzXiMAuqT3xGc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782989318; c=relaxed/simple; bh=y543E+SNzJ2jIsNnAwCXgRRnBCZeScaoKTfLwi1alas=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NuPbkIKZ21ar0JLUiyAv0GgRaRQxfvgGMvZXGwdx5uHEKcy/TeKTkKzzLq4kFgidsiogEeXhZLqo+Aq/S3Lr6M79Hl0gNUrQyPG2TuOX+say6NAb1pQ9DdSgbflXBAyLuK2mL/yktsf3P/ZabgoYUWJSPlX2whxpXWDY7Exs1AI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=n9bW1SAi; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="n9bW1SAi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59B1D1F000E9; Thu, 2 Jul 2026 10:48:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782989317; bh=o6xCmOWRhtd0dh68F+qKexIAS2YEOpSkOc+brs5B0AM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=n9bW1SAiICSOx8sVaUEhLHGkQUnWLWANkEiXfFWXAQyAroAs8rOz1q33o0e1SDnrS prSfW+mtv7CvWoW85T9HaaFOiKYkk4nlQqoQL+qBFZfYNQTTndA9wIZ4lp7vsD2a6q 6w61P1+I5OHcM0P9b9F2mRK165VNG/f74WAKnS3fIkxXp/m+rN9cHeajVS4ti4gsLM YRCCh2Ue4gGiGvOOlB2JStGQf+xhky+7b+4BnW84e7kpciBXJygOn1iXWLbni23njU kp+biaTiZrn3m/QcbK6pssxgw6SHhIhnJ/4F7W66Sl73CMpyNRXsl5SMuyJtYQYg7a KbkD3EtwB+5Ug== Date: Thu, 2 Jul 2026 11:48:24 +0100 From: Lorenzo Stoakes To: Andrew Morton Cc: Usama Arif , david@kernel.org, chrisl@kernel.org, kasong@tencent.com, ziy@nvidia.com, linux-mm@kvack.org, ying.huang@linux.alibaba.com, Baoquan He , willy@infradead.org, youngjun.park@lge.com, hannes@cmpxchg.org, riel@surriel.com, shakeel.butt@linux.dev, alex@ghiti.fr, kas@kernel.org, baohua@kernel.org, dev.jain@arm.com, baolin.wang@linux.alibaba.com, npache@redhat.com, "Liam R. Howlett" , ryan.roberts@arm.com, Vlastimil Babka , lance.yang@linux.dev, linux-kernel@vger.kernel.org, nphamcs@gmail.com, shikemeng@huaweicloud.com, kernel-team@meta.com, Mike Rapoport Subject: Re: [PATCH 0/6] mm: preparatory patches for PMD level swap entries Message-ID: References: <20260630164143.1595669-1-usama.arif@linux.dev> <20260630125024.6c079ea708630d99708e26f6@linux-foundation.org> <20260701164613.008aa13cb6187ec9597bf652@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260701164613.008aa13cb6187ec9597bf652@linux-foundation.org> +cc Mike re: CI. On Wed, Jul 01, 2026 at 04:46:13PM -0700, Andrew Morton wrote: > On Wed, 1 Jul 2026 09:04:33 +0100 Lorenzo Stoakes wrote: > > > On Tue, Jun 30, 2026 at 12:50:24PM -0700, Andrew Morton wrote: > > > On Tue, 30 Jun 2026 09:34:37 -0700 Usama Arif wrote: > > > > > > > This is the preparatory part of the PMD page table swapin work. > > > > > > Thanks. > > > > > > This comes reasonably reviewed, so I'll queue it in mm-new. > > > > > > Why? > > > > > > - Human review coverage and AI review make me believe this isn't the > > > final version at all, but I do believe this is something we want in > > > 7.2, and getting it under test early will help to push it along. > > > > > > - Getting it in there early means that others will base their work on > > > material which will probably be upstreamed this cycle, so this gives > > > them a more accurate base against which to work. > > > > > > Sashiko did find a lot to talk about, some of it pre-existing so can > > > people who work on this code please take a look at > > > > > > https://sashiko.dev/#/patchset/20260630164143.1595669-1-usama.arif@linux.dev > > > > > > > > > > Hm, my understanding was that mm-new is where we take everything submitted for > > early testing? > > > > Did something change? > > mm-new has always been a few day front-end to mm-unstable. To protect > linux-next from brand new material. It serves no other purpose. Well it only serves a purpose if it gives us better testing. We have a CI running tests now though, Mike - is that predicated on material being in mm-new or does it just grab the email? If the CI is just grabbing email I wonder whether there's much purpose in the mm-new branch at all. > > Almost. I'll very occasionally use it for short-term not-for-upstream > playthings. > > > Generally anything submitted early in the cycle is expected to land in the cycle > > unless there's significant adverse review or other reasons it can't be taken. > > Yup. Don't want anything in mm.git which isn't expected to be > upstreamed in the next merge window. > > Nowadays I'm reluctant to add anything which hasn't had a decent scan > from reviewers. If it's something I'd particularly like to get > upstreamed I'll very occasionally add it early, to help push it along. Well the question is what is considered to be a decent scan from reviewers? Is it tags on all patches? As a glance at mm-new suggests otherwise. I guess moving forwards with mm-next we can figure out the rules specifically on this kind of thing. Maintainer signoff is the key indicator of something being acceptable for the cycle. But I think probably if we have a topic branch of stuff we're considering for upstream (but not the stable branch which should require maintainer signoff), a good proportion of tags (and review from everybody matters and is important) maybe should be the metric. I am wondering about my series(es) in general though as I'm likely to cause some significant merge conflict pain for people if that's delayed too much. But sure we can wait for more review coverage on that I guess. Thanks, Lorenzo