> Note that you have provided a *clean* page back to the kernel (even if > it was dirty when you got it from the kernel); as a consequence, the > kernel might delete the page now, losing any changes that have been > made So you must mark it precious even if you didn't modify it. In > otherwords, the return of the page to you, and you supplying it back, > has cleared the dirty bit for the page.
Hmm. True. But then only if the dirty bit was set in the memory_object_data_return message. > > And yet, what if milliseconds from now we get another message to > > write to the page? Again, we need to go through the same song and > > dance -- request the page, write to it and return it to the kernel. > > Um, who is issuing these requests to you to write the page? >From what I have read, there are often two different interfaces to access a memory object: one exposed by the kernel via the vm_map family of messages and a second exposed by the manager that does file i/o-like operations. For instance, in the Hurd we have io_read and io_write. > 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. > What is the problem you are trying to solve? 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. >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. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
