Re: [patch 14/21] x86: add hugepagesz option on 64-bit

[Nick Piggin <npiggin@suse.de>]

On Tue, Jun 03, 2008 at 10:57:52PM +0200, Andi Kleen wrote:
> > The downside of something like this is that you have yet another data
> > structure to manage.  Andi, do you think something like this would be
> > workable?
> 
> The reason I don't like your proposal is that it makes only sense
> with a lot of hugepage sizes being active at the same time. But the
> API (one mount per size) doesn't really scale to that anyways.
> It should support two (as on x86), three if you stretch it, but
> anything beyond would be difficult.
> If you really wanted to support a zillion sizes you would at least
> first need a different flexible interface that completely hides page
> sizes.
> Otherwise you would drive both sysadmins and programmers crazy and 
> overlong command lines would be the smallest of their problems
> With two or even three sizes only the whole thing is not needed and my original
> scheme works fine IMHO.
> 
> That is why I was also sceptical of the newly proposed sysfs interfaces. 
> For two or three numbers you don't need a sysfs interface.

I do think your proc enhancements are clever, and you're right that for
the current setup they are pretty workable. The reason I haven't submitted
them in this round is because they do cause libhugetlbfs failures...
maybe that's just because the regression suite does really dumb parsing,
and nothing important will break, but it is the only thing I have to go on
so I have to give it some credit ;)

With the sysfs API, we have a way to control the other hstates, so it
takes a little importance off the proc interface.

sysfs doesn't appear to give a huge improvement yet (although I still
think it is nicer), but I think the hugetlbfs guys want to have control
over which nodes things get allocated on etc. so I think proc really
was going to run out of steam at some point.

Anyway, my point is just that sysfs is the way forward, but I'm also not
against people tinkering with /proc if it isn't going to cause problems.

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>