Re: hugepage: Strict page reservation for hugepage inodes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 08, 2006 at 04:19:13PM -0800, Chen, Kenneth W wrote:
> David Gibson wrote on Wednesday, March 08, 2006 3:52 PM
> > But I don't see that recording all the mapped ranges will avoid the
> > need for the fault serialization.  At least the version of apw's
> > reservation patch I looked at most recently would certainly still
> > suffer from the alloc/instantiate race on the last hugepage in the
> > system.
> 
> No, it doesn't.  Because with strict commit accounting, you know that
> every hugetlb page is accounted for.  So there is no backout path for
> multiple instantiation race.  Thread that lost in the race will always
> go back to retry in hugetlb_no_page().  And since reservation is also
> accounted in a global variable, total hugetlb pool won't fall below
> what was reserved plus what is in use.  Even if sys admin tries to
> reduce hugetlb pool, kernel won't release any pages that are
> reserved.

Hrm..ok.  Clearly I'm looking at the wrong version of the patch - what
I have is from the prefaulting days, anyway.

Though.. you must still need a backout path for PRIVATE mappings,
which would make the logic rather complex.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux