From: Alexey Korolev <akorolev@infradead.org>
To: Mel Gorman <mel@csn.ul.ie>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [PATCH 0/3]HTLB mapping for drivers (take 2)
Date: Mon, 17 Aug 2009 23:24:09 +0100 (BST) [thread overview]
Message-ID: <alpine.LFD.2.00.0908172317470.32114@casper.infradead.org> (raw)
Hi,
The patch set listed below provides device drivers with the ability to
map memory regions to user space via HTLB interfaces.
Why we need it?
Device drivers often need to map memory regions to user-space to allow
efficient data handling in user mode. Involving hugetlb mapping may
bring performance gain if mapped regions are relatively large. Our tests
showed that it is possible to gain up to 7% performance if hugetlb
mapping is enabled. In my case involving hugetlb starts to make sense if
buffer is more or equal to 4MB. Since typically, device throughput
increase over time there are more and more reasons to involve huge pages
to remap large regions.
For example hugetlb remapping could be important for performance of Data
acquisition systems (logic analyzers, DSO), Network monitoring systems
(packet capture), HD video capture/frame buffer and probably other.
How it is implemented?
Implementation and idea is very close to what is already done in
ipc/shm.c.
We create file on hugetlbfs vfsmount point and populate file with pages
we want to mmap. Then we associate hugetlbfs file mapping with file
mapping we want to access.
So typical procedure for mapping of huge pages to userspace by drivers
should be:
1 Allocate some huge pages
2 Create file on vfs mount of hugetlbfs
3 Add pages to page cache of mapping associated with hugetlbfs file
4 Replace file's mapping with the hugetlbfs file mapping
..............
5 Remove pages from page cache
6 Remove hugetlbfs file
7 Free pages
(Please find example in following messages)
Detailed description is given in the following messages.
Thanks a lot to Mel Gorman who gave good advice and code prototype and
Stephen Donnelly for assistance in description composing.
Alexey
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2009-08-17 22:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-17 22:24 Alexey Korolev [this message]
2009-08-18 10:29 ` Eric Munson
2009-08-19 5:48 ` Alexey Korolev
2009-08-19 10:05 ` Mel Gorman
2009-08-19 10:35 ` Eric B Munson
2009-08-20 7:03 ` Alexey Korolev
2009-08-25 10:47 ` Mel Gorman
2009-08-25 11:00 ` Benjamin Herrenschmidt
2009-08-25 11:10 ` Mel Gorman
2009-08-26 9:58 ` Benjamin Herrenschmidt
2009-08-26 10:05 ` Mel Gorman
2009-08-24 6:14 ` Alexey Korolev
2009-08-25 10:53 ` Mel Gorman
2009-08-27 12:02 ` Alexey Korolev
2009-08-27 12:50 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.00.0908172317470.32114@casper.infradead.org \
--to=akorolev@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox