kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: Valdis.Kletnieks@vt.edu (Valdis.Kletnieks at vt.edu)
To: kernelnewbies@lists.kernelnewbies.org
Subject: User space memory
Date: Tue, 12 Mar 2013 10:29:04 -0400	[thread overview]
Message-ID: <42972.1363098544@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Tue, 12 Mar 2013 18:38:05 +0530." <CACPKTANtQAvK2k+K686D3M7nxAJA8MyZmqA=qdR+fyg2LfBtxw@mail.gmail.com>

On Tue, 12 Mar 2013 18:38:05 +0530, Prabhu nath said:

> On Sun, Mar 10, 2013 at 11:30 PM, Christoph Seitz <c.seitz@tu-bs.de> wrote:

> > I use a char device for reading and writing from/to a pcie dma card.
> > Especially the read function makes me some headache. The user allocates
> > some memory with posix_memalign and call the read function on the
> > device, so that the devices knows where to write to. My driver now uses
> > get_user_pages() to pin the user pages. The memory has never been
> > written or read by the user, so it's not yet in the RAM, right? And
> > get_user_pages returns a valid number of pages, but for every page the
> > same struct. (respectively the same pointer). Is there any way to ensure
> > that the user pages are in the ram and get_user_pages returns a valid
> > page array?
> >
>
> If you know the RAM physical address range you can figure out by doing the
> following
>     *page_to_pfn(page_ptr) << 12*;
>     where page_ptr is a struct page * returned by get_user_pages().
>    * page_to_pfn()* will return the pfn of the corresponding page frame and
> left shifting by 12 bits will give you page frame base address.

Unfortunately, that doesn't actually tell you what Christoph was
worried about - is the page *currently* in RAM?  For that, you need
to check some bits in the pfn once you find it.

Also, note the following:

It's not always 12, because not everything uses a 4K page - consider hugepage
support, or Power and Itanium where the pages are bigger and often several
different sizes are supported.  There's an API for the current page size. Use
it. :)

Also, there's an API for pinning pages so they *stay* in RAM so you can target
them for I/O.  Use that. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130312/de5bbe31/attachment-0001.bin 

  parent reply	other threads:[~2013-03-12 14:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-10 18:00 User space memory Christoph Seitz
2013-03-12 13:08 ` Prabhu nath
2013-03-12 14:03   ` Christoph Seitz
2013-03-12 17:18     ` Valdis.Kletnieks at vt.edu
2013-03-12 14:29   ` Valdis.Kletnieks at vt.edu [this message]
2013-03-13  5:18     ` Prabhu nath

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=42972.1363098544@turing-police.cc.vt.edu \
    --to=valdis.kletnieks@vt.edu \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /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).