On Thu, 20 Feb 2014, Marcelo Tosatti wrote: > Mel has clearly has no objection to the command line. You can also > allocate 2M pages at runtime, and that is no reason for "hugepages=" > interface to not exist. >
The "hugepages=" interface does exist and for good reason, when fragmentation is such that you cannot allocate that number of hugepages at runtime easily. That's lacking from your use case: why can't your customer do it from an initscript? So far, all you've said is that your customer wants 8 1GB hugepages on node 0 for a 32GB machine. > There is a number of parameters that are modifiable via the kernel > command line, so following your reasoning, they should all be removed, > because it can be done at runtime. > 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. > Yes, we'd like to maintain backwards compatibility. > Good, see below. > > Thus, it seems, the easiest addition would have > > been "hugepagesnode=" which I've mentioned several times, there's no > > reason to implement yet another command line option purely as a shorthand > > which hugepage_node=1:2:1G is and in a very cryptic way. > > Can you state your suggestion clearly (or point to such messages), and > list the advantages of it versus the proposed patch ? > My suggestion was posted on the same day this patchset was posted: http://marc.info/?l=linux-kernel&m=139241967514884 it would be helpful if you read the thread before asking for something that has been repeated over and over. There's no need to implement a shorthand that combines a few kernel command line options. That's not the issue, anymore, though, since there's no need for the patchset to begin with if you can dynamically allocate 1GB hugepages at runtime. If your customer wanted 4096 2MB hugepages on node 0 instead of 8 1GB hugepages on node 0, we'd not be having this conversation. Do I really need to do your work for you and work on 1GB hugepages at runtime, which many more people would be interested in? Or are we just seeking the easiest way out here with something that shuts the customer up and leaves a kernel command line option that we'll need to maintain to avoid breaking backwards compatibility in the future? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
