From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f197.google.com (mail-wr0-f197.google.com [209.85.128.197]) by kanga.kvack.org (Postfix) with ESMTP id A07016B0292 for ; Thu, 10 Aug 2017 11:33:05 -0400 (EDT) Received: by mail-wr0-f197.google.com with SMTP id v102so1514716wrb.2 for ; Thu, 10 Aug 2017 08:33:05 -0700 (PDT) Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id e12si5392103wrd.321.2017.08.10.08.33.04 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 10 Aug 2017 08:33:04 -0700 (PDT) Date: Thu, 10 Aug 2017 17:33:01 +0200 From: Michal Hocko Subject: Re: [RFC PATCH v2 0/6] mm, memory_hotplug: allocate memmap from hotadded memory Message-ID: <20170810153300.GA23863@dhcp22.suse.cz> References: <20170801124111.28881-1-mhocko@kernel.org> <20170807070029.GD32434@dhcp22.suse.cz> <20170810114052.GP23863@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Dan Williams Cc: Linux MM , Andrew Morton , Mel Gorman , Vlastimil Babka , Andrea Arcangeli , Jerome Glisse , Reza Arbab , Yasuaki Ishimatsu , qiuxishi@huawei.com, Kani Toshimitsu , slaoub@gmail.com, Joonsoo Kim , Andi Kleen , Daniel Kiper , Igor Mammedov , Vitaly Kuznetsov , LKML , Benjamin Herrenschmidt , Catalin Marinas , Fenghua Yu , Gerald Schaefer , Heiko Carstens , "H. Peter Anvin" , Ingo Molnar , Martin Schwidefsky , Michael Ellerman , Paul Mackerras , Thomas Gleixner , Tony Luck , Will Deacon , X86 ML On Thu 10-08-17 08:27:56, Dan Williams wrote: > On Thu, Aug 10, 2017 at 4:40 AM, Michal Hocko wrote: > > On Tue 08-08-17 13:01:36, Dan Williams wrote: > >> On Mon, Aug 7, 2017 at 12:00 AM, Michal Hocko wrote: > >> > Any comments? Especially for the arch specific? Has anybody had a chance > >> > to test this? I do not want to rush this but I would be really glag if > >> > we could push this work in 4.14 merge window. > >> > >> Hi Michal, > >> > >> I'm interested in taking a look at this especially if we might be able > >> to get rid of vmem_altmap, but this is currently stuck behind some > >> other work in my queue. I'll try to circle back in the next couple > >> weeks. > > > > Well, vmem_altmap was there and easy to reuse. Replacing with something > > else is certainly possible but I really need something to hook a > > dedicated allocator into vmemmap code. > > Oh, you're reusing it, that's great. Then I definitely got the wrong > impression from the first glance at the patch set, I'll dig deeper. yeah, reusing and extending a bit so I would highly appreciate if you could have a look I am doing that in a sane way. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org