Re: [PATCH 0/3] NUMA boot hash allocation interleaving

Martin J. Bligh
2004-12-15T07:15:09Z

>> > > I originally was a bit worried about the TLB usage, but it doesn't
>> > > seem to be a too big issue (hopefully the benchmarks weren't too
>> > > micro though)
>> >
>> > Well, as long as we stripe on large page boundaries, it should be fine,
>> > I'd think. On PPC64, it'll screw the SLB, but ... tough ;-) We can either
>> > turn it off, or only do it on things larger than the segment size, and
>> > just round-robin the rest, or allocate from node with most free.
>>
>> Is there a reasonably easy-to-use existing infrastructure to do this?
>
> No. It will be a lot of work actually, requiring new code for
> each architecture and may even be impossible on some.
> The current hugetlb code is not really suitable for this
> because it requires an preallocated pool and only works
> for user space.

Well hold on a sec. We don't need to use the hugepages pool for this,
do we? This is the same as using huge page mappings for the whole of
kernel space on ia32. As long as it's a kernel mapping, and 16MB aligned
and contig, we get it for free, surely?

> Also at least on IA64 the large page size is usually 1-2GB
> and that would seem to be a little too large to me for
> interleaving purposes. Also it may prevent the purpose
> you implemented it - not using too much memory from a single
> node.

Yes, that'd bork it. But I thought that they had a large sheaf of
mapping sizes to chose from on ia64?

> Using other page sizes would be probably tricky because the
> linux VM can currently barely deal with two page sizes.
> I suspect handling more would need some VM infrastructure effort
> at least in the changed port.

For the general case I'd agree. But this is a setup-time only tweak
of the static kernel mapping, isn't it?

I'm not saying it needs doing now. But it's an interesting future
enhancement.

M.