All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <roland@topspin.com>
To: hpa@zytor.com (H. Peter Anvin)
Cc: linux-kernel@vger.kernel.org
Subject: Re: chasing the four level page table
Date: Fri, 14 Jan 2005 19:37:29 -0800	[thread overview]
Message-ID: <521xcnl5vq.fsf@topspin.com> (raw)
In-Reply-To: <csa0kn$4eg$1@terminus.zytor.com> (H. Peter Anvin's message of "Sat, 15 Jan 2005 02:54:15 +0000 (UTC)")

    ak> Perhaps we should add a get_user_phys() or somesuch for this.

    hpa> There seems to be at least two classes of device drivers --
    hpa> graphics and RDMA -- which have a genuine need to DMA user
    hpa> pages, after appropriate locking, of course.

I'm working on InfiniBand drivers, which will be doing RDMA.  I'm
probably missing something, but get_user_pages() seems to be all I
need -- I don't see how get_user_phys() would help me.  Of course I
need to do dma_map_sg() or the like to get an address I can pass to
the InfiniBand device but I don't see anything wrong with that.

There are some issues around fork() and copy-on-write, but those
really require more access to vma handling than page tables.  What
would be nice would be an equivalent to do_mlock() that also sets or
clears the VM_DONTCOPY flag.  This is because an RDMA application
wants to do something like mlock() to keep any pages to be DMAed
present, but even after doing mlock(), if the application forks and
touches one of these locked pages, the COW will move the page to a new
physical address.

 - Roland

  reply	other threads:[~2005-01-15  3:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-06 17:17 chasing the four level page table Jon Smirl
2005-01-06 18:12 ` Andi Kleen
2005-01-06 18:36   ` Jon Smirl
2005-01-06 19:38     ` Andi Kleen
2005-01-06 20:05       ` Jon Smirl
2005-01-06 21:41         ` Dave Jones
2005-01-08  5:22           ` Jon Smirl
2005-01-15  2:54             ` H. Peter Anvin
2005-01-15  3:37               ` Roland Dreier [this message]
2005-01-15  4:24               ` Andi Kleen
2005-01-15  5:59                 ` Jon Smirl

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=521xcnl5vq.fsf@topspin.com \
    --to=roland@topspin.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.