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

["Ken Chen" <kenchen@google.com>]

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?

--
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>