[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: slow access to files
From: |
Thomas Bushnell, BSG |
Subject: |
Re: slow access to files |
Date: |
06 Nov 2001 10:45:53 -0800 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
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.