Messages in this thread | | | Subject | Re: [RFC][PATCH] make /proc/pid/pagemap work with huge pages and return page size | From | Matt Mackall <> | Date | Fri, 29 Feb 2008 16:46:12 -0600 |
| |
On Fri, 2008-02-29 at 14:30 -0800, Dave Hansen wrote: > On Thu, 2008-02-28 at 17:15 -0800, Matt Mackall wrote: > > > The only issue is that this is *after* the code has decided that a > > > particular virtual area is for huge pages. The best arch-generic > > > interface I know for that is: is_vm_hugetlb_page(), but that is > > > VMA-based. Perhaps we should change the pagemap walk to pass the VMA > > > around. > > > > I'd rather avoid that. Requiring a VMA to poke at these things shouldn't > > -really- be necessary. > > Yeah, this is strictly true. But, it also assumes that we have all of > the data about where large pages are based on the contents of the > pagetables alone. It's possible that we can derive this, or code up a > bunch of arch-specific functions to do this, but it certainly doesn't > exist today. I'm just not keen on going and learning about how each and > every architecture encodes hugetlb information in their pagetables. :( > > The fact is that we treat pagetables in hugetlb areas completely > differently than normal pages. All of the generic functions that deal > with pagetables magically punt over to the hugetlb code when they see a > hugetlb VMA. > > I think although it isn't strictly necessary, it is going to save a ton > of work to just pass the VMAs around.
Well in any case, step 1 should be to finalize the interface. Let's start with a single patch that does nothing but move the exported bits around and makes room for the page shift bits. Are we agreed on what that should look like now?
ps: my laptop died on Tuesday, so I'll be struggling to even read email until its replacement arrives.
-- Mathematics is the supreme nostalgia of our time.
| |