Messages in this thread | | | Subject | Re: [PATCH 0/3]HTLB mapping for drivers (take 2) | From | Benjamin Herrenschmidt <> | Date | Tue, 25 Aug 2009 21:00:54 +1000 |
| |
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.
I looked at it a while back and it occured to me (and Nick) that ideally, we should split hugetlb and hugetlbfs.
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), 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 ? :-)
Cheers, Ben.
| |