Re: [PATCH 4/4] hugetlb: add hugepages_node= command-line option

[David Rientjes]

On Mon, 17 Feb 2014, Luiz Capitulino wrote:

> hugepages= and hugepages_node= are similar, but have different semantics.
> 
> hugepagesz= and hugepages= create a pool of huge pages of the specified size.
> This means that the number of times you specify those options are limited by
> the number of different huge pages sizes an arch supports. For x86_64 for
> example, this limit is two so one would not specify those options more than
> two times. And this doesn't count default_hugepagesz=, which allows you to
> drop one hugepagesz= option.
> 
> hugepages_node= allows you to allocate huge pages per node, so the number of
> times you can specify this option is limited by the number of nodes. Also,
> hugepages_node= create the pools, if necessary (at least one will be). For
> this reason I think it makes a lot of sense to have different options.
> 

I understand you may want to add as much code as you can to the boot code 
so that you can parse all this information in short-form, and it's 
understood that it's possible to specify a different number of varying 
hugepage sizes on individual nodes, but let's come back down to reality 
here.

Lacking from your entire patchset is a specific example of what you want 
to do.  So I think we're all guessing what exactly your usecase is and we 
aren't getting any help.  Are you really suggesting that a customer wants 
to allocate 4 1GB hugepages on node 0, 12 2MB hugepages on node 0, 6 1GB 
hugepages on node 1, 24 2MB hugepages on node 1, 2 1GB hugepages on node 
2, 100 2MB hugepages on node 3, etc?  Please.

If that's actually the usecase then I'll renew my objection to the entire 
patchset and say you want to add the ability to dynamically allocate 1GB 
pages and free them at runtime early in initscripts.  If something is 
going to be added to init code in the kernel then it better be trivial 
since all this can be duplicated in userspace if you really want to be 
fussy about it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/