Re: slow access to files

[Thomas Bushnell, BSG]

nisse@lysator.liu.se (Niels Möller) writes:

> Farid Hajji <farid.hajji@ob.kamp.net> 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.