[EMAIL PROTECTED] (Niels Möller) writes: > Farid Hajji <[EMAIL PROTECTED]> writes: > > > The problem right now is that there is no memory sharing between normal > > clients and the filesystem translators. Here, data is simply copied across > > a costly IPC path, thus wasting a lot of CPU cycles. > > I thought Mach had some mechanism that allowed ipc to send larger > amounts of memory (say a few pages at a time) between processes. If > that mechanism isn't used by Hurd I/O, it would be interesting to know > why.
There is such a mechanism; it's vm_copy. Normal IPC paths use the equivalent when something is sent "out of band". In such cases, no actual copy happens; the pages are marked copy-on-write. There are some cases where attempts to do copy-on-write will instead cause the kernel to do an immediate copy, and indeed, these do happen on paged-on-pages. When a pager hands a page to the kernel and says "this is the data", a copy is normally immediately made. It's nearly impossible, given the existing VM architecture inside Mach, to fix that one copy. So there is one copy per pagein, as a rule. > The only copy that really is needed (i.e. is hard to get rid of, no > matter what fancy ipc or kernel features you have) is the final one > into the buffer the user provided to read. That buffer should be > private to the process, and it isn't usually page aligned, so it has > to be copied, and on the Hurd, that copying ought to happen in glibc. You betcha. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
