On Wed, 16 May 2007, Nick Piggin wrote: > Andrew Morton wrote: > > I need to work out what to do with > > > > mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch > > mm-merge-populate-and-nopage-into-fault-fixes-nonlinear.patch > > mm-merge-populate-and-nopage-into-fault-fixes-nonlinear-doc-fix.patch > > mm-merge-populate-and-nopage-into-fault-fixes-nonlinear-fix.patch > > mm-merge-nopfn-into-fault.patch > > convert-hugetlbfs-to-use-vm_ops-fault.patch > > mm-remove-legacy-cruft.patch > > mm-debug-check-for-the-fault-vs-invalidate-race.patch > > mm-fix-clear_page_dirty_for_io-vs-fault-race.patch > > > > Probably merge them, I guess. Hugh had concerns, I think over small > > additional overhead from the lock_page()? That's right, the overhead of the lock_page()/unlock_page() in the common path of faulting, and of the extra call to unmap_mapping_range() when truncating (because page lock doesn't satisfactorily replace the old sequence count when COWing). > Yes he did. It seems to only be noticable in microbenchmarks. So far, yes. I expect it'll surface in some reallife workload sometime, but let's not get too depressed about that. I guess your blithe "Scalability is not an issue" comment still irks me. > In my opinion not enough to withhold pagecache corruption bug fixes. It is a pity to be adding overhead to a common path in order to fix such very rare cases, but yes, we probably have to live with that. > Still, I have some lock_page speedup work that eliminates that regression > anyway. Again, rather too blithely said. You have a deep well of ingenuity, but I doubt it can actually wash away all of the small overhead added. > However, Hugh hasn't exactly said yes or no yet... Getting a "yes" or "no" out of me is very hard work indeed. But I didn't realize that was gating this work: if the world had to wait on me, we'd be in trouble. I think there are quite a few people eager to see the subsequent ->fault changes go in. And I think I'd just like to minimize the difference between -mm and mainline, so maximize comprehensibilty, by getting this all in. I've not heard of any correctness issues with it, and we all agree that the page lock there is attractively simple. If I ever find a better way of handling it, I'm free to send patches in future, after all. Did that sound something like a "yes"? Hugh - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
