On Thu, Apr 06, 2023 at 03:23:11PM +0200, David Hildenbrand wrote: > > > > > > Often, when you have to start making a list of things that a patch does, it > > > might make sense to split some of the items into separate patches such that you > > > can avoid lists and just explain in list-free text how the pieces in the patch > > > fit together. > > > > > > I'd suggest splitting this patch into logical pieces. For example, separating > > > the general profit calculation/exposure from the per-mm profit and the per-mm > > > ksm type indication. > > > > > > > Originally these were individual patches. If I recall correctly Johannes > > Weiner wanted them as one patch. I can certainly split them again. > > That's why I remember that v1 contained more patches :) > > Again, just my opinion on patches that require a description in form of a > list ... My concern was the initial splitting of patch 1. I found it easier to review with the new prctl() being one logical change, and fully implemented in one go. The changelog is still in the form of a list, but it essentially enumerates diff hunks that make up the interface. No objection to splitting out the multiple sysfs knobs, though! The strategy I usually follow is this: 1. Split out changes based on user-visible behavior (new prctl(), new sysfs knob) 2. Extract changes made along the way that have stand-alone value in existing code (bug fixes, simplifying/documenting tricky sections, cleanups). 3. Split out noisy prep work such as renames and refactors that make the user-visible functional changes more difficult to understand. and then order the series into sections 2, 3, and 1.
