On 5/3/05, David Addison <[EMAIL PROTECTED]> wrote:
> We believe the IOPROC patch is generic and powerful and would allow other
> RDMA NICs to solve the page registration problems in a different manner.
> For NICs which require page registration, new VM hooks can be used to avoid
> pages being unl
> On 5/3/05, David Addison <[EMAIL PROTECTED]> wrote:
> > as our recent IOPROC patch on lkml shows, it's not that invasive. There
> > are just 24 hooks added to the Linux VM code paths - which we have been
> > able to
> > maintain outside the mainline tree for many years now.
> > As these hooks
An ex post facto notification of a PTE change would enable the RDMA
Device driver to know when a Memory Region had been invalidated
so that it could probably declare an access violation and tear all
the connections using it down.
But if the intent is to allow it to migrate the memory region to th
On Tue, May 03, 2005 at 09:42:12AM +0100, David Addison wrote:
> >This doesn't scale well as more cards are added to the box.
> >I think I understand why it's good for single cards though.
>
> With the IOPROC patch the device driver hooks are registered on a per
> process or perhaps better still,
Grant Grundler wrote:
On Fri, Apr 29, 2005 at 08:22:24PM +0200, Brice Goglin wrote:
For instance, instead of adding PROT_DONT/ALWAYSCOPY, you may use
an ioproc hook in the fork path. This hook (a function in your driver)
would be called for each registered page. It will decide whether
the page shou
Ronald G. Minnich wrote:
On Fri, 29 Apr 2005, Greg Lindahl wrote:
It doesn't imply that there's an MMU, either. I know that Myricom uses a
little lookup routine in software on their nic, which most people
wouldn't call an MMU. I don't know what Mellanox does for this, they
don't talk much about wha
Greg Lindahl wrote:
On Fri, Apr 29, 2005 at 12:33:54PM -0700, Grant Grundler wrote:
Being mostly clueless about Quadrics implementation, I'm probably
missing something that makes Quadrics a MMU but not the IB variants.
Can someone clue me in please?
As far as I can tell it's mostly a marketing dist
oops, hit the send to soon. Finishing the response...
On 4/29/05, Caitlin Bestler <[EMAIL PROTECTED]> wrote:
> On 4/29/05, Roland Dreier <[EMAIL PROTECTED]> wrote:
> > Bill> I'm very confused at this point. Can you briefly explain how
> > Bill> this works, or point me to a description? I d
On Fri, 29 Apr 2005, Caitlin Bestler wrote:
> One is that the RDMA hardware, however it is marketed, essentially
> needs to act as an MMU. That means that it has to be synchronized
> with normal MMU. The traditional sledge-hammer approach to
ah ha! his RDMA mmu just crashed his mm
On 4/29/05, Roland Dreier <[EMAIL PROTECTED]> wrote:
> Bill> I'm very confused at this point. Can you briefly explain how
> Bill> this works, or point me to a description? I don't see how
> Bill> you could do user level I/O without registering the memory
> Bill> with the hardware. I
On Fri, Apr 29, 2005 at 03:07:40PM -0600, Ronald G. Minnich wrote:
> On Fri, 29 Apr 2005, Greg Lindahl wrote:
>
> > It doesn't imply that there's an MMU, either. I know that Myricom uses a
> > little lookup routine in software on their nic, which most people
> > wouldn't call an MMU. I don't know
On Fri, 29 Apr 2005, Greg Lindahl wrote:
> It doesn't imply that there's an MMU, either. I know that Myricom uses a
> little lookup routine in software on their nic, which most people
> wouldn't call an MMU. I don't know what Mellanox does for this, they
> don't talk much about what's hardware a
On Fri, 29 Apr 2005, Rimmer, Todd wrote:
> But that implies the hardware has an MMU and it also puts an interrupt
> in the path per page sent.
yes. it does. and it doesn't do per page sent, just per page that has no
pte on the nic when received.
ron
___
> Todd> But that implies the hardware has an MMU and it also puts an
> Todd> interrupt in the path per page sent.
>
> Well, there's one interrupt per non-resident page sent. But nearly
> all of the time the page will be present.
It doesn't imply that there's an MMU, either. I know that M
On Fri, 29 Apr 2005, Bill Jordan wrote:
> I'm very confused at this point. Can you briefly explain how this works,
> or point me to a description? I don't see how you could do user level
> I/O without registering the memory with the hardware. I'm especially
> confused by the comment (may not hav
Todd> But that implies the hardware has an MMU and it also puts an
Todd> interrupt in the path per page sent.
Well, there's one interrupt per non-resident page sent. But nearly
all of the time the page will be present.
Todd> Wasn't the assertion that there was no MMU in the hardware?
> You add a hook to the kernel so it tells you if a page is about to be
> paged out or otherwise move. Then you set a bit in the adapter's page
> table so that it won't try to access that page without telling you.
> If the adapter asks for the page, you get the kernel to fault the page
> in and pr
Bill> I'm very confused at this point. Can you briefly explain how
Bill> this works, or point me to a description? I don't see how
Bill> you could do user level I/O without registering the memory
Bill> with the hardware. I'm especially confused by the comment
Bill> (may not have
On 4/29/05, Greg Lindahl <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 29, 2005 at 12:33:54PM -0700, Grant Grundler wrote:
>
> > Being mostly clueless about Quadrics implementation, I'm probably
> > missing something that makes Quadrics a MMU but not the IB variants.
> > Can someone clue me in please?
On Fri, Apr 29, 2005 at 12:33:54PM -0700, Grant Grundler wrote:
> Being mostly clueless about Quadrics implementation, I'm probably
> missing something that makes Quadrics a MMU but not the IB variants.
> Can someone clue me in please?
As far as I can tell it's mostly a marketing distinction. Man
Bill> Are you suggesting making the partial pages their own VMA,
Bill> or marking the entire buffer with this flag? I originally
Bill> thought the entire buffer should be copy on fork (instead of
Bill> copy on write), and I believe this is the path Mellanox was
Bill> pursing wit
On Fri, Apr 29, 2005 at 08:22:24PM +0200, Brice Goglin wrote:
> For instance, instead of adding PROT_DONT/ALWAYSCOPY, you may use
> an ioproc hook in the fork path. This hook (a function in your driver)
> would be called for each registered page. It will decide whether
> the page should be pre-copi
Brice> Do you plan to work with David Addison from Quadrics ? For
Brice> sure, your hardware have very different capabilities. But
Brice> ioproc_ops is a really nice solution and might help a lot
Brice> when dealing with deregistration and fork.
I'm following the discussion with
Roland Dreier a écrit :
2) For fork() support:
a) Extend mprotect() with PROT_DONTCOPY so processes can avoid
copy-on-write problems.
b) (maybe someday?) Add a VM_ALWAYSCOPY flag and extend mprotect()
with PROT_ALWAYSCOPY so processes can mark pages to be
pre-copied into chi
24 matches
Mail list logo
