From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by kanga.kvack.org (Postfix) with ESMTP id E2F636B0031 for ; Thu, 10 Oct 2013 12:46:30 -0400 (EDT) Received: by mail-pd0-f178.google.com with SMTP id w10so2856438pde.23 for ; Thu, 10 Oct 2013 09:46:30 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id i13so358760qae.9 for ; Thu, 10 Oct 2013 09:46:28 -0700 (PDT) Date: Thu, 10 Oct 2013 12:46:23 -0400 From: Tejun Heo Subject: Re: [PATCH part1 v6 4/6] x86/mem-hotplug: Support initialize page tables in bottom-up Message-ID: <20131010164623.GD13276@htj.dyndns.org> References: <20131009164449.GG22495@htj.dyndns.org> <52558EEF.4050009@gmail.com> <20131009192040.GA5592@mtj.dyndns.org> <1381352311.5429.115.camel@misato.fc.hp.com> <20131009211136.GH5592@mtj.dyndns.org> <1381363135.5429.138.camel@misato.fc.hp.com> <20131010010029.GA10900@mtj.dyndns.org> <1381415809.24268.40.camel@misato.fc.hp.com> <20131010153518.GB13276@htj.dyndns.org> <1381422249.24268.68.camel@misato.fc.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1381422249.24268.68.camel@misato.fc.hp.com> Sender: owner-linux-mm@kvack.org List-ID: To: Toshi Kani Cc: Zhang Yanfei , "H. Peter Anvin" , Andrew Morton , "Rafael J . Wysocki" , "lenb@kernel.org" , Thomas Gleixner , "mingo@elte.hu" , Wanpeng Li , Thomas Renninger , Yinghai Lu , Jiang Liu , Wen Congyang , Lai Jiangshan , "isimatu.yasuaki@jp.fujitsu.com" , "izumi.taku@jp.fujitsu.com" , Mel Gorman , Minchan Kim , "mina86@mina86.com" , "gong.chen@linux.intel.com" , "vasilis.liaskovitis@profitbricks.com" , "lwoodman@redhat.com" , Rik van Riel , "jweiner@redhat.com" , "prarit@redhat.com" , "x86@kernel.org" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Linux MM , "linux-acpi@vger.kernel.org" , "imtangchen@gmail.com" , Zhang Yanfei , Tang Chen Hey, On Thu, Oct 10, 2013 at 10:24:09AM -0600, Toshi Kani wrote: > > We're going round and round. You're saying that using SRAT isn't > > worse than what came before while failing to illustrate how committing > > to invasive changes would eventually lead to something better. "it > > isn't worse" isn't much of an argument. > > We did avoid moving up the ACPI table init function per your suggestion. > I guess I do not understand why you still concerned about using SRAT... As you wrote above, SRAT is not enough to support device granularity. We need to parse the device hierarchy too before setting up page tables and one of the previous arguments was "it's only SRAT". It doesn't instill confidence when there doesn't seem to be much long term planning going on especially as the general quality of the patches isn't particularly high. I find it difficult to believe that this effort as it currently stands is likely to reach full solution and as such it feels much safer to opt for a simpler, less dangerous approach for immedate use, for which either approach doesn't make much of difference. Thanks. -- tejun -- 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