Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759922Ab3HNL1r (ORCPT ); Wed, 14 Aug 2013 07:27:47 -0400 Received: from mail-ea0-f173.google.com ([209.85.215.173]:44981 "EHLO mail-ea0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759901Ab3HNL1p (ORCPT ); Wed, 14 Aug 2013 07:27:45 -0400 Date: Wed, 14 Aug 2013 13:27:41 +0200 From: Ingo Molnar To: Linus Torvalds Cc: Nathan Zimmer , Mike Travis , Peter Anvin , Linux Kernel Mailing List , linux-mm , Robin Holt , Rob Landley , Daniel J Blueman , Andrew Morton , Greg Kroah-Hartman , Yinghai Lu , Mel Gorman Subject: Re: [RFC v3 0/5] Transparent on-demand struct page initialization embedded in the buddy allocator Message-ID: <20130814112741.GB13772@gmail.com> References: <1375465467-40488-1-git-send-email-nzimmer@sgi.com> <1376344480-156708-1-git-send-email-nzimmer@sgi.com> <520A6DFC.1070201@sgi.com> <20130813231020.GA22667@asylum.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2102 Lines: 57 * Linus Torvalds wrote: > On Tue, Aug 13, 2013 at 4:10 PM, Nathan Zimmer wrote: > > > > The only mm structure we are adding to is a new flag in page->flags. > > That didn't seem too much. > > I don't agree. > > I see only downsides, and no upsides. Doing the same thing *without* the > downsides seems straightforward, so I simply see no reason for any extra > flags or tests at runtime. The code as presented clearly looks more involved and neither simple nor zero-cost - I was hoping for a much more simple approach. I see three solutions: - Speed up the synchronous memory init code: live migrate to the node being set up via set_cpus_allowed(), to make sure the init is always fast and local. Pros: if it solves the problem then mem init is still synchronous, deterministic and essentially equivalent to what we do today - so relatively simple and well-tested, with no 'large machine' special path. Cons: it might not be enough and we might not have scheduling enabled on the affected nodes yet. - Speed up the synchronous memory init code by paralellizing the key, most expensive initialization portion of setting up the page head arrays to per node, via SMP function-calls. Pros: by far the fastest synchronous option. (It will also test the power budget and the mains fuses right during bootup.) Cons: more complex and depends on SMP cross-calls being available at mem init time. Not necessarily hotplug friendly. - Avoid the problem by punting to async mem init. Pros: it gets us to a minimal working system quickly and leaves the memory code relatively untouched. Disadvantages: makes memory state asynchronous and non-deterministic. Stats either fluctuate shortly after bootup or have to be faked. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/