Re: hugepage: Strict page reservation for hugepage inodes

[Andrew Morton <akpm@osdl.org>]

"'David Gibson'" <david@gibson.dropbear.id.au> wrote:
>
> On Wed, Mar 08, 2006 at 10:38:58AM -0800, Chen, Kenneth W wrote:
> > David Gibson wrote on Wednesday, March 08, 2006 2:23 AM
> > > Yes.  This is a simplifying assumption.  I know of no real application
> > > that will waste pages because of this behaviour.  If you know one,
> > > maybe we will need to reconsider.
> > > 
> > > > I have an idea. How about to record all the start/end address of
> > > > huge page mmaping of the inode? Long long ago, there was a patch at 
> > > > http://marc.theaimsgroup.com/?l=lse-tech&m=108187931924134&w=2.
> > > > Of course, we need port it to the latest kernel if this idea is better.
> > > 
> > > I know the patch - I was going to port it to the current kernel, but
> > > came up with my patch instead, because it seemed like a simpler
> > > approach.
> > 
> > I really think the Variable length reservation system is the way to go
> > for tracking hugetlb commit.  It is more robust and in my opinion, it
> > is better than traverse the page cache radix tree.  At least, you don't
> > have to worry about all the race condition there.  Oh, it also can get
> > rid of the hugetlb_instantiation_mutex that was introduced.  Someday,
> > people is going to scream at you for serializing hugetlb fault path.
> 
> Well, not my decision, or yours I think.  wli?  akpm?

You're the guy who's doing all the work...

The linear list walk is a worry.  Every time we have one of those someone
gets bitten by it.

It's rather similar to the vma rbtree.

The radix-tree supports both in-order traversal and O(log(n)) lookup.  For
non-duplicated-key items it _should_ be OK?  (It could be used for
duplicated-key items too, btw).