> > > I can understand you wanting to avoid the overhead of the minor faults > > > resulting from using page_mkclean(), but I'm not sure its worth it. > > > > It would be nice if the cost of MS_ASYNC wouldn't be too high. And I > > do have the feeling that minor faults are far more expensive than > > cleaning the dirty bit in the ptes. > > > > Do you have any numbers? > > None what so ever, but I always think of msync as a rare function > (infrequent when compared to (minor) faults overall). But I don't have > numbers backing that up either. It depends entirely on the usage pattern. I can imagine this sort of use: mmap write lots of data to memory msync(MS_ASYNC) overwrite previous data msync(MS_ASYNC) ... In this case write protecting and faulting the pages will be slower, than just checking the page tables. > Also, the radix tree scan you do isn't exactly cheap either. > > So what I was wondering is whether its worth optimizing this at the cost > of another rmap walker. (one with very dubious semantics at that - it > clears the pte dirty bit but doesn't particularly care about that nor > does it respect the PG_dirty / PTE dirty relation) I don't think this is dubious. The pte dirty bit in this case means, that the page was modified _since_the_last_call_ of this function. The PG_dirty on the other hand means, that the page will need to be written back. So they have completely different meanings. Thanks, Miklos - 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
