Messages in this thread | | | Date | Wed, 8 Mar 2006 16:29:32 -0800 | From | Andrew Morton <> | Subject | Re: hugepage: Strict page reservation for hugepage inodes |
| |
"'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).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |