Re: memory_object_lock_request and memory_object_data_return fnord

[Neal H Walfield]

> In principle, we need to do this already!  The glaringest security
> issue with the Hurd right now is the assumption that all users will
> just take their pagers and hand them to the kernel with vm_map. But
> they might play as "kernels" themselves.  To deal with this, the
> pagers need to be able to deal with multiple "kernels", and also have
> strategies for dealing with recalcitrant "kernels" that aren't
> behaving properly.

Wow!  I had not thought of that.  Thanks.

> > From what I can see, the pager_memcpy function can be extremely slow.
> > Just consider what happens when we just want to replace a page on disk
> > (which has not yet been read in to memory).  pager_memcpy causes a
> > page fault.  The kernel sends a message to the manager which reads the
> > page from disk (which is completely unnecessary), then, we write to
> > the page and eventually, it is flushed back to the disk.  This is even
> > worse if we are writing to multiple pages -- our thread and the
> > manager thread play ping-pong!  This could be avoided by acquiring as
> > much of the range up front as possible.
> 
> Why do you think this is so horrible?  This is just demand paging.

In the scenario case, we do a completely unnecessary read!  That is
not demand paging; that is a waste.

> What's supposed to be going on behind the scenes is that the kernel
> should detect that you are faulting the pages in sequentially, and ask
> for pages from the pager ahead of time, optimizing the sequential
> access case.

But the manager knows; why force the kernel to guess?  Say we send:

        io_read (file, data, vm_page_size * 4, 0, &amount)

By the time the kernel detects a sequential read, it is already too
late to be of any use.