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 7501D3839B1 for ; Wed, 3 Jun 2026 01:48:50 +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=1780451331; cv=none; b=UJhhdmAhYfnmmRS4ouoNTHN1ToOqduWZO2OSeTmeXEGLyUvRXeOJF/SuYHcVjBQqLJ/UL9cJn/SdWEu6i9Cl3hj1+4tlRLFCf2lVq50tXOuXhRZld6J+A90R2UcX5B5jxVPHKUpRV08HUuRZbPxA7/U94rRevuvzY/NyOesbBF4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780451331; c=relaxed/simple; bh=E8l+wXET8/oSaXHB8j54+sr0qt9udGJnPpsYLpDBgWg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=szEUUMXsXfCS+F2ONwOJAY7WPfQtxW8xO3tX2ChfGlWNZRlGM1D4pT7J2+TduzhERe/loddK/wC2pISk73Nc47VSrf90Wy06Itk8Pln2Cwq+6ycOeAIDikDjPl+nl/SbqoMbI+3vXVFRqgB9zBUaUzq1TYkwlqXKNcLUUInvOuc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jeEi5+CS; 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="jeEi5+CS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D92D81F00898; Wed, 3 Jun 2026 01:48:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780451330; bh=cYGrk2aHBiiXWhM3IGNiUFXlkm290VxyZC1ZHOCt5Qs=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=jeEi5+CSh4X3UBeZ7lWep7Vk5L5UKIw5mYMWzDbWplkfmgOcW6Fjf7k9xD9oWISwU qTtOjmh0+bUkSS5rZZeWb5axYsgOcIfsVMbZlPSzxywJGktJHJr6GzgmAHZUwW33I1 QfYlIIK3nFfFxFCaHS4MmBFUvsFMIKez5V30+IFTo+k2fTnptUaCZH3gtcWCl2w/dr JXr52HpvGiomrb9OR35TOiGPM3RVnczGiMmRM3xrUuHQYSc8LX0DHlX1jZZY7rZ8XJ iX1UnCwR6tADFDb+C9m83TkAoQ5bEp3o0Ze6sw8WmST9hrnVp2VSERHgAHThXDAOSR trS6ibkCyxN2g== From: SeongJae Park To: "David Hildenbrand (Arm)" Cc: SeongJae Park , "Vlastimil Babka (SUSE)" , Lorenzo Stoakes , Nico Pache , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, liam@infradead.org, mhocko@suse.com, rppt@kernel.org, vbabka@suse.cz, willy@infradead.org Subject: Re: Process (was Re: [PATCH mm-hotfixes-unstable v18 00/14] khugepaged: add mTHP) collapse support Date: Tue, 2 Jun 2026 18:48:40 -0700 Message-ID: <20260603014841.90322-1-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <58b45d62-37b3-4006-b738-08992f502b58@kernel.org> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Tue, 2 Jun 2026 15:16:27 +0200 "David Hildenbrand (Arm)" wrote: > On 6/2/26 15:08, Vlastimil Babka (SUSE) wrote: > > On 6/2/26 14:58, David Hildenbrand (Arm) wrote: > >> On 6/2/26 14:47, Vlastimil Babka (SUSE) wrote: > >>> > >>> The problem is that the patches would not be applied on top of the > >>> integration tree, so it doesn't make sense to base them on it in the first > >>> place. Unless they target the next cycle, where the integration tree would > >>> first become part of rc1, which would be the new base for all the > >>> submaintainer trees. > >> Why does that matter? > > > > Well, as longs as there are no conflicts, it probably doesn't. > > Yes. > > > > >> For example, the slab-next tree gets merged into the mm-next tree. Submitter > >> will send against mm-next. > >> > >> The slab maintainer will cherry-pick the patches on top of slab-next. From where > >> they end up in mm-next. > > > > Note slab-next itself might be a collection of topic branches and it might > > be more flexible to create another topic branch (based on rc1) and merge it, > > than apply stuff on top of a product of merging. > > Right, and I assume that the maintainer would then either try to fix it up > himself, or ask the submitter to base against a specific branch. (e.g., against > another topic branch etc). So I understand we agree we will allow peoplee to base their patches on whatever makes sense. I like this flexibility. The slight difference I show is that David suggests to use mm-next as the default baseline, and later rebase on subcomponent tree if needed. Meanwhile, some subcomponent maintainers think the opposite direction make sense. Submitter use the appropriate subcomponent maintainer-suggested tree as the default, and the submaintainers handle merge conflicts of their for-mm-next branch. I think both could work, and we will learn from trying. But from a subcomponent maintainer's persepctive, I was thnking our process will be more like the second approach. And I still slightly feeling that will be simpler for at least a subcomponent maintainer. Why I feel so is like below. In the first approach, as Vlastimil and David described already, there are chances of conflicts at picking mm-next based submitter's patch on subcomponent tree. How frequenct and complex the conflicts will be is questionable. But it feels like I will have to deal it with submitters. E.g., asking rebase to submitters, like David mentioned. I think some of submitters might not very familiar with git and the mm process, so I feel it might be not very simple always. In the second appraoch, I expect less chances of conflicts when picking submitter patches on subcomponent trees. The subcomponent maintainer will still get conflicts with mm-next and have to fix it. But in this case, the subcomponent maintainer will be able to do that nearly alone. Or, they will work with the mm-next maintainer and/or other subcomponent maintainers. I pretty suree the other maintainers will be familiar with git and the process. So I expect less headaches. Also, this kind of conflict resolving between subcomponent maintainer and mm-next trees is samely required for the first approach, anyway. mm-next maintainer's perspective might see many different things, though. I will be more than glad to be learn what I'm missing and get enlightened. Anyway I think both approaches may work, and we can learn from others and trying on our own. I will be happy to help when there is something that I can help. :) Thanks, SJ [...]