From: Alexey Korolev <akorolex@gmail.com>
To: linux-mm@kvack.org, Mel Gorman <mel@csn.ul.ie>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Huge pages for device drivers
Date: Fri, 12 Jun 2009 16:41:19 +1200 [thread overview]
Message-ID: <202cde0e0906112141n634c1bd6n15ec1ac42faa36d3@mail.gmail.com> (raw)
Hi,
I'm investigating the possibility to involve huge pages mappings in
order to increase data analysing performance in case of device
drivers.
The model we have is more or less common: We have driver which
allocates memory and configures DMA. This memory is then shared to
user mode applications to allow user-mode daemons to analyse and
process the data.
In this case Huge TLB could be quite useful because DMA buffers are
large ~64MB - 1024MB and desired performance of data analysing in user
mode is huge ~10Gb/s.
If I properly understood the code the only available approach is :
Allocate huge page memory in user mode application. Then supply it to
driver. Then do magic to obtain physical address and try to configure
DMAs. But this approach leads to big bunch of problems because: 1.
Virtual address can be remapped to another physical address. 2. It is
necessary to manage GFP flags manually (GFP_DMA32 must be set).
So the question I have:
1. Is it definitely the only way to provide huge page mappings in this
case. May be I miss something.
2. Is there any plans to provide interfaces for device drivers to map
huge pages? What are possible issues to have it?
Thanks,
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-06-12 4:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-12 4:41 Alexey Korolev [this message]
2009-06-12 14:30 ` Huge pages for device drivers Mel Gorman
2009-06-15 6:58 ` Alexey Korolev
2009-06-15 9:23 ` 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=202cde0e0906112141n634c1bd6n15ec1ac42faa36d3@mail.gmail.com \
--to=akorolex@gmail.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--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;
as well as URLs for NNTP newsgroup(s).