Re: [PATCH 5/5] [hugetlb] Try to grow pool for MAP_SHARED mappings

Ken Chen
2007-07-13T21:38:58Z

On 7/13/07, Christoph Lameter <clameter@sgi.com> wrote:
> On Fri, 13 Jul 2007, Adam Litke wrote:
>
> > To be honest, I just don't think a global hugetlb pool and cpusets are
> > compatible, period. I wonder if moving to the mempool interface and
>
> Sorry no. We always had per node pools. There is no need to have per
> cpuset pools.

Yeah, per node pool is fine. But we need per cpuset reservation to
preserve current hugetlb semantics on shared mapping.

> > Hmm, I see what you mean, but cpusets are already broken because we use
> > the global resv_huge_pages counter. I realize that's what the
> > cpuset_mems_nr() thing was meant to address but it's not correct.
>
> Well the global reserve counter causes a big reduction in performance
> since it requires the serialization of the hugetlb faults. Could we please
> get this straigthened out? This serialization somehow snuck in when I was
> not looking and it screws up multiple things.

Sadly, global serialization has some nice property. It is now used in
three paths that I'm aware of:
(1) shared mapping reservation count
(2) linked list protection in unmap_hugepage_range
(3) shared page table on hugetlb mapping.

i suppose (2) and (3) can be moved into per-inode lock?