linux-kernel - Re: [PATCH 0/3]HTLB mapping for drivers (take 2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 25 Aug 2009 21:00:54 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Mel Gorman <mel@....ul.ie>
Cc:	Alexey Korolev <akorolex@...il.com>,
	Eric Munson <linux-mm@...bm.net>,
	Alexey Korolev <akorolev@...radead.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3]HTLB mapping for drivers (take 2)

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/