[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOAebxsAXC8CgoRdeD4=1ePwoB6TeqprZgnkenU-aCeKGv_p+w@mail.gmail.com>
Date: Wed, 14 Feb 2018 09:14:17 -0500
From: Pavel Tatashin <pasha.tatashin@...cle.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Steve Sistare <steven.sistare@...cle.com>,
Daniel Jordan <daniel.m.jordan@...cle.com>,
Mel Gorman <mgorman@...hsingularity.net>,
Michal Hocko <mhocko@...e.com>,
Linux Memory Management List <linux-mm@...ck.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Vlastimil Babka <vbabka@...e.cz>,
Bharata B Rao <bharata@...ux.vnet.ibm.com>,
Thomas Gleixner <tglx@...utronix.de>, mingo@...hat.com,
hpa@...or.com, x86@...nel.org, dan.j.williams@...el.com,
kirill.shutemov@...ux.intel.com, bhe@...hat.com
Subject: Re: [PATCH v3 0/4] optimize memory hotplug
Hi Ingo,
Thank you very much for your review. I will address spelling issues,
and will also try to split the patch #4. Regarding runtime concern
for patch #3: the extra checking is only performed when the both of
the following CONFIGs are enabled:
CONFIG_DEBUG_VM=y
CONFIG_DEBUG_VM_PGFLAGS=y
I do not expect either of these to be ever enabled on a production systems.
Thank you,
Pavel
On Wed, Feb 14, 2018 at 3:09 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Andrew Morton <akpm@...ux-foundation.org> wrote:
>
>> On Tue, 13 Feb 2018 14:31:55 -0500 Pavel Tatashin <pasha.tatashin@...cle.com> wrote:
>>
>> > This patchset:
>> > - Improves hotplug performance by eliminating a number of
>> > struct page traverses during memory hotplug.
>> >
>> > - Fixes some issues with hotplugging, where boundaries
>> > were not properly checked. And on x86 block size was not properly aligned
>> > with end of memory
>> >
>> > - Also, potentially improves boot performance by eliminating condition from
>> > __init_single_page().
>> >
>> > - Adds robustness by verifying that that struct pages are correctly
>> > poisoned when flags are accessed.
>>
>> I'm now attempting to get a 100% review rate on MM patches, which is
>> why I started adding my Reviewed-by: when I do that thing.
>>
>> I'm not familiar enough with this code to add my own Reviewed-by:, and
>> we'll need to figure out what to do in such cases. I shall be sending
>> out periodic review-status summaries.
>>
>> If you're able to identify a suitable reviewer for this work and to
>> offer them beer, that would help. Let's see what happens as the weeks
>> unfold.
>
> The largest patch, fix patch #2, looks good to me and fixes a real bug.
> Patch #1 and #3 also look good to me (assuming the runtime overhead
> added by patch #3 is OK to you):
>
> Reviewed-by: Ingo Molnar <mingo@...nel.org>
>
> (I suspect patch #1 and patch #2 should also get a Cc: stable.)
>
> Patch #4 is too large to review IMO: it should be split up into as many patches as
> practically possible. That will also help bisectability, should anything break.
>
> Before applying these patches please fix changelog and code comment spelling.
>
> But it's all good stuff AFAICS!
>
> Thanks,
>
> Ingo
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@...ck.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>
Powered by blists - more mailing lists