lkml.org 
[lkml]   [2020]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v2 2/3] mm/memory_hotplug: document why shuffle_zone() is relevant
On Mon, Jun 22, 2020 at 12:28 AM David Hildenbrand <david@redhat.com> wrote:
>
> On 20.06.20 03:41, Dan Williams wrote:
> > On Fri, Jun 19, 2020 at 6:00 AM David Hildenbrand <david@redhat.com> wrote:
> >>
> >> It's not completely obvious why we have to shuffle the complete zone, as
> >> some sort of shuffling is already performed when onlining pages via
> >> __free_one_page(), placing MAX_ORDER-1 pages either to the head or the tail
> >> of the freelist. Let's document why we have to shuffle the complete zone
> >> when exposing larger, contiguous physical memory areas to the buddy.
> >>
> >
> > How about?
> >
> > Fixes: e900a918b098 ("mm: shuffle initial free memory to improve
> > memory-side-cache utilization")
> >
> > ...just like Patch1 since that original commit was missing the proper
> > commentary in the code?
>
> Hmm, mixed feelings. I (working for a distributor :) ) prefer fixes tags
> for actual BUGs, as described in
>
> Documentation/process/submitting-patches.rst: "If your patch fixes a bug
> in a specific commit, e.g. you found an issue using ``git bisect``,
> please use the 'Fixes:' tag with the first 12 characters" ...
>
> So unless there are strong feelings, I'll not add a fixes tag (although
> I agree, that it should have been contained in the original commit).

It doesn't need to be "Fixes", but how about at least mentioning the
original commit as a breadcrumb so that some future "git blame"
archaeology effort is streamlined.

\
 
 \ /
  Last update: 2020-06-23 23:18    [W:0.090 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site