Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Jul 2007 15:48:39 +0200
From:      "Nicolas Cormier" <n.cormier@gmail.com>
To:        "Robert Watson" <rwatson@freebsd.org>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: p_vmspace in syscall
Message-ID:  <c4630b800707040648k560ad15bgb0e198bef7899adf@mail.gmail.com>
In-Reply-To: <20070704141257.M37059@fledge.watson.org>
References:  <c4630b800707020954s4aa0be68t2d5f3eb864f2dda5@mail.gmail.com> <20070704091349.T42421@fledge.watson.org> <c4630b800707040200n4a6de4f5j2008f60fefb149e6@mail.gmail.com> <20070704120624.W37059@fledge.watson.org> <c4630b800707040604r296632dap562f6e6bc0bfe330@mail.gmail.com> <20070704141257.M37059@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 7/4/07, Robert Watson <rwatson@freebsd.org> wrote:
> What do you mean by a network allocator?  How do you plan to use these pages?

First I just want to access a local copy of a distant buffer.
After the goal is to share memory between hosts (no concurrent access).

> If you haven't already, you should look at the zero-copy socket code in
> uipc_cow.c.  The main criticism of this approach has been that it uses
> copy-on-write, leading to potential IPIs for VM shootdowns, etc.  An
> alternative, more along the lines of IO-Lite, would be to allow user space to
> explicitly abandon the page on send, then map a new page to replace it.  In
> which case you might consider a variation on the send system call that accepts
> only page-aligned arguments and has the effect of unmapping the pages that are
> sent.  In neither case, on the transmit side, does this require an
> modification to the kernel memory allocator.
>
> The receive side has always been more tricky to deal with...
>

Ok I will take a look at uipc_cow.c,
Thank you
-- 
Nicolas Cormier



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c4630b800707040648k560ad15bgb0e198bef7899adf>