linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Korolev <akorolex@gmail.com>
To: Eric Munson <linux-mm@mgebm.net>
Cc: Alexey Korolev <akorolev@infradead.org>,
	Mel Gorman <mel@csn.ul.ie>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3]HTLB mapping for drivers (take 2)
Date: Wed, 19 Aug 2009 17:48:11 +1200	[thread overview]
Message-ID: <202cde0e0908182248we01324em2d24b9e741727a7b@mail.gmail.com> (raw)
In-Reply-To: <56e00de0908180329p2a37da3fp43ddcb8c2d63336a@mail.gmail.com>

Hi,
>
> It sounds like this patch set working towards the same goal as my
> MAP_HUGETLB set.  The only difference I see is you allocate huge page
> at a time and (if I am understanding the patch) fault the page in
> immediately, where MAP_HUGETLB only faults pages as needed.  Does the
> MAP_HUGETLB patch set provide the functionality that you need, and if
> not, what can be done to provide what you need?
>
> Eric
>
Thanks a lot for willing to help. I'll be much appreciate if you have
an interesting idea how HTLB mapping for drivers can be done.

It is better to describe use case in order to make it clear what needs
to be done.
Driver provides mapping of device DMA buffers to user level
applications. User level applications process the data.
Device is using a master DMA to send data to the user buffer, buffer
size can be >1GB and performance is very important. (So huge pages
mapping really makes sense.)

In addition we have to mention that:
1. It is hard for user to tell how much huge pages needs to be
reserved by the driver.
2. Devices add constrains on memory regions. For example it needs to
be contiguous with in the physical address space. It is necessary to
have ability to specify special gfp flags.
3 The HW needs to access physical memory before the user level
software can access it. (Hugetlbfs picks up pages on page fault from
pool).
It means memory allocation needs to be driven by device driver.

Original idea was: create hugetlbfs file which has common mapping with
device file. Allocate memory. Populate page cache of hugetlbfs file
with allocated pages.
When fault occurs, page will be taken from page cache and then
remapped to user space by hugetlbfs.

Another possible approach is described here:
http://marc.info/?l=linux-mm&m=125065257431410&w=2
But currently not sure  will it work or not.


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>

  reply	other threads:[~2009-08-19  5:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-17 22:24 Alexey Korolev
2009-08-18 10:29 ` Eric Munson
2009-08-19  5:48   ` Alexey Korolev [this message]
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=202cde0e0908182248we01324em2d24b9e741727a7b@mail.gmail.com \
    --to=akorolex@gmail.com \
    --cc=akorolev@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-mm@mgebm.net \
    --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