[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: memory_object_lock_request and memory_object_data_return fnord

From: Neal H Walfield
Subject: Re: memory_object_lock_request and memory_object_data_return fnord
Date: 13 Mar 2002 22:14:03 -0500
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1

> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]