Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754832AbaBUKHS (ORCPT ); Fri, 21 Feb 2014 05:07:18 -0500 Received: from mail-pb0-f47.google.com ([209.85.160.47]:47252 "EHLO mail-pb0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753950AbaBUKHN (ORCPT ); Fri, 21 Feb 2014 05:07:13 -0500 Date: Fri, 21 Feb 2014 02:07:08 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Marcelo Tosatti cc: Luiz Capitulino , Andrew Morton , Mel Gorman , Andrea Arcangeli , Andi Kleen , Rik van Riel , davidlohr@hp.com, isimatu.yasuaki@jp.fujitsu.com, yinghai@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 4/4] hugetlb: add hugepages_node= command-line option In-Reply-To: <20140221022800.GA30230@amt.cnet> Message-ID: References: <20140214225810.57e854cb@redhat.com> <20140217085622.39b39cac@redhat.com> <20140218123013.GA20609@amt.cnet> <20140220022254.GA25898@amt.cnet> <20140220213407.GA11048@amt.cnet> <20140221022800.GA30230@amt.cnet> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 20 Feb 2014, Marcelo Tosatti wrote: > > 1GB is of such granularity that you'd typically either be (a) oom so that > > your userspace couldn't even start, or (b) have enough memory such that > > userspace would be able to start and allocate them dynamically through an > > initscript. > > There are a number of kernel command line parameters which can be > modified in runtime as well. > We could also make the kernel command line implement a shell scripting language of your choice. There's no technical objection to it, of course you can do it, but is it in the interest of the kernel in terms of maintainability? > You are asking what is the use-case. > I'm asking what the use case is because it's still not explained. You say a customer wants 8 1GB hugepages on node 0 on a 32GB machine. Perfectly understandable. The only thing missing, and is practically begging to be answered in this thread, is why must it be done on the command line? That would be the justification for the patchset. Andrew asked for Luiz to elaborate originally and even today the use case is not well described. If you're asking for a maintenance burden to be accepted forever, it seems like as part of your due diligence that you would show why it must be done that way. Being the easiest or "pragmatic" is not it, there is a much larger set of people who would be interested in dynamic allocation, myself and Google included. > A particular distribution is irrelevant. What you want is a non default > distribution of 1GB hugepages. > > Can you agree with that ? (forget about particular values, please). > I agree that your customer wants a non-default distribution of 1GB hugepages, yes, that's clear. The questions that have not been answered: why must it be done this way as opposed to runtime? If 1GB hugepages could be dynamically allocated, would your customer be able to use it? If not, why not? If dynamic allocation resolves all the issues, then is this patchset a needless maintenance burden if we had such support today? -- 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/