Messages in this thread | | | Date | Tue, 25 Aug 2009 12:10:32 +0100 | From | Mel Gorman <> | Subject | Re: [PATCH 0/3]HTLB mapping for drivers (take 2) |
| |
On Tue, Aug 25, 2009 at 09:00:54PM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2009-08-25 at 11:47 +0100, Mel Gorman wrote: > > > Why? One hugepage of default size will be one TLB entry. Each hugepage > > after that will be additional TLB entries so there is no savings on > > translation overhead. > > > > Getting contiguous pages beyond the hugepage boundary is not a matter > > for GFP flags. > > Note: This patch reminds me of something else I had on the backburner > for a while and never got a chance to actually implement... > > There's various cases of drivers that could have good uses of hugetlb > mappings of device memory. For example, framebuffers. >
Where is the buffer located? If it's in kernel space, than any contiguous allocation will be automatically backed by huge PTEs. As framebuffer allocation is probably happening early in boot, just calling alloc_pages() might do?
> I looked at it a while back and it occured to me (and Nick) that > ideally, we should split hugetlb and hugetlbfs. >
Yeah, you're not the first to come to that conclusion :)
> Basically, on one side, we have the (mostly arch specific) populating > and walking of page tables with hugetlb translations, associated huge > VMAs, etc... > > On the other side, hugetlbfs is backing that with memory. > > Ideally, the former would have some kind of "standard" ops that > hugetlbfs can hook into for the existing case (moving some stuff out of > the common data structure and splitting it in two),
Adam Litke at one point posted a pagetable-abstraction that would have been the first step on a path like this. It hurt the normal fastpath though and was ultimately put aside.
> allowing the driver > to instanciate hugetlb VMAs that are backed up by something else, > typically a simple mapping of IOs. > > Anybody wants to do that or I keep it on my back burner until the time I > finally get to do it ? :-) >
It's the sort of thing that has been resisted in the past, largely because the only user at the time was about transparent hugepage promotion/demotion. It would need to be a really strong incentive to revive the effort.
-- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab
| |