RE: [PATCH 3/3] hugetlb: fix absurd HugePages_Rsvd

Christoph Lameter
2006-10-26T20:59:46Z

On Thu, 26 Oct 2006, Chen, Kenneth W wrote:

> One performance fix I have in mind is to only use the mutex when system is down to 1
> free hugetlb page. That is the real reason why mutex got introduced. I'm implementing
> it right now and hope it will restore most if not all of the performance we lost.

Right. Its a heavily special case that brings down performance for
everyone else. Maybe setup a boundary via /proc/sys/vm/nr_hugepages_xxx
below which this is checked?

> Christoph, the shared page table for hugetlb also need your advice here in the path
> of allocating page table page. It takes a per inode spin lock in order to find
> shareable page table page. Do you think it will cause problem? I hope not.

Well it depends on how huge pages are used. If you use one file per
process then there is no issue.

Even if we have a common huge file spanning multiple nodes: If you just
take the inode lock to find the page then I think its fine. We have the
same issues with the page lock for regular pages. But please avoid locks
while zeroing a huge page.