Date: Tue, 28 May 2013 10:43:18 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Zaphod Beeblebrox <zbeeble@gmail.com> Cc: Luigi Rizzo <rizzo@iet.unipi.it>, FreeBSD Current <current@FreeBSD.org> Subject: Re: copyin+copyout in one step ? Message-ID: <0D03D7B6-7530-4CCD-859B-FD6374E40424@FreeBSD.org> In-Reply-To: <CACpH0Mf57zA0LqEykuYdj1KQyqA%2BqUyTYrxJCsiWdLYPRBU-PA@mail.gmail.com> References: <20130527233801.GA32042@onelab2.iet.unipi.it> <CACpH0Mf57zA0LqEykuYdj1KQyqA%2BqUyTYrxJCsiWdLYPRBU-PA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28 May 2013, at 05:56, Zaphod Beeblebrox <zbeeble@gmail.com> wrote: > Urm... Isn't the use of shared memory the more obvious way to transfer = data > between processes? Am I missing some nuance? I can't speak for Luigi's use-case, but the Binder APIs in BeOS and = Android call for this kind of copy. The receiving process contains a = ring buffer and the messages are pushed into it. You could implement = this in shared memory, but only if you trusted the sender not to modify = the data at incorrect times or write invalid values into the metadata = (or, in the case of Binder, to forge the pid / uid of the sender, which = it attached to each message). The kernel must act as an intermediary to = enforce correct use of the buffer and also to allow the caller to block = until space is available (perhaps by scheduling the receiver to run for = a bit) without spinning and to allow multiple writers to be queued when = there is no space, rather than have them racing. The buffers are in the = receiver's memory space because it is designed for resource constrained = environments and for malicious parties to communicate, so it avoids a = potential DoS by filling up kmem with buffers - a process that create a = load of receive ports will simply fill up its own address space and die. In the specific case of binder, you can avoid the overhead of extra VM = lookups by mapping the buffer into the address space of every sender = when you open the connection, but marking its access as privileged mode = only. This means that you'll be doing a simple copy. You can also = align the receive buffer in such a way that the consume counter is on a = different page to the rest of the data structure, allowing you to get a = page fault when the buffer transitions from full to non-full and there = are messages waiting. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0D03D7B6-7530-4CCD-859B-FD6374E40424>