Date: Wed, 4 Jul 2007 14:19:45 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Nicolas Cormier <n.cormier@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: p_vmspace in syscall Message-ID: <20070704141257.M37059@fledge.watson.org> In-Reply-To: <c4630b800707040604r296632dap562f6e6bc0bfe330@mail.gmail.com> References: <c4630b800707020954s4aa0be68t2d5f3eb864f2dda5@mail.gmail.com> <20070704091349.T42421@fledge.watson.org> <c4630b800707040200n4a6de4f5j2008f60fefb149e6@mail.gmail.com> <20070704120624.W37059@fledge.watson.org> <c4630b800707040604r296632dap562f6e6bc0bfe330@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Jul 2007, Nicolas Cormier wrote: > Currently I'm just trying to play with kernel/modules/vm ... I'm a newbie in > kernel development and I just want to make a little prototype of an > in-kernel network allocator. To start I only need to map a page (1024 bytes) > from kernel to user process. This memory will never be used by the kernel > between the call of net(malloc/attach) and the call of net(detach/free). So > user and kernel will never use this page at the same time. > >> The underlying point here is that there is a model by which VM is managed >> -- pages, pagers, memory objects, mappings, address spaces, etc. We can't >> just talk about pages being shared or mapped, we need to think about what >> is to be accomplished, and how to map that into the abstractions that >> already exist. Memory comes in different flavours, and generally speaking, >> you don't want to use pages that come from malloc(9) for sharing with >> userspace, so we need to think about what kind of memory you do need. > > Thank you for your answer. Right now, I just want to do it as easily as > possible, I don't know if this kind of project could interest other persons > ? It is ok for me to work more on it later on, if there is any further > interest in doing it. What do you mean by a network allocator? How do you plan to use these pages? 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... Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070704141257.M37059>