Neal H Walfield <[EMAIL PROTECTED]> writes: > Hmm. True. But then only if the dirty bit was set in the > memory_object_data_return message.
Oh right, somehow I forgot that the kernel handed you the dirty bit. > > Ideally, if you need to write to the page, you do it the same way > > libdiskfs does: map the pager yourself, and write to it that way. > > Well, the Mach documentation explicitly says to avoid this as it often > leads to deadlock. Only because they are thinking about limited numbers of threads. We always run the pagers in their own threads, so it's no trouble. > I am trying to understand the motivation for having a relatively > complex interface to manage page ownership which, in the Hurd, we do > not use. Ah, the principal motivation is to allow, for example, a pager to manage pages shared between many "kernels". The reason to demand pages back or require locking, in general, is so that you can hand them up to other "kernels". 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. > 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. 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. Thomas _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
