On Mon, 18 Jul 2011 18:33:58 +0200 Alexander Graf <agraf@xxxxxxx> wrote: > > On 18.07.2011, at 18:18, Scott Wood wrote: > > > They're pinned by get_user_pages_fast(). We (potentially) write to them, so > > we should mark them dirty, because they are dirty. It's up to the rest > > of Linux what to do with that. Will being pinned stop updates from being > > written out if it is file-backed? And eventually the vm will be destroyed > > (or the tlb reconfigured) and the pages will be unpinned. > > Hrm. How much overhead do we add to the exit-to-userspace path with this? Not sure -- probably not too much for anonymous memory, compared to the rest of the cost of a heavyweight exit. On e500 the tlb array is 4 pages, and each set_page_dirty_lock() will just do a few bit operations. > I completely agree that we should mark them dirty when closing, but I'm > not fully convinced a "we dirty them so we should declare them dirty at > random times" pays off against possible substantial slowdowns due to the > marking. Keep in mind that this is the MMIO case which isn't _that_ seldom. If we can convince ourselves nothing bad can happen, fine. I did it here because this is the point at which the API says the contents of the memory are well-defined. If it is file-backed, and userspace does a sync on a heavyweight exit, shouldn't the the right thing get written to disk? Could any other weird things happen? I'm not familiar enough with that part of the kernel to say right away that it's safe. If we need to start making assumptions about what userspace is going to do with this memory in order for it to be safe, then the restrictions should be written into the API, and we should be sure that the performance gain is worth it. -Scott -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
