On Tue, 2 Aug 2005, Hugh Dickins wrote:

quoted

Yes, good point. If the thing is still marked dirty in the TLB, some other 
thread might be writing to the page after we've cleared dirty but before 
we've flushed the TLB - causing the new dirty bit to be lost. I think.

Would that matter?  Yes, if vmscan sneaked in at some point while
page_table_lock is dropped, and wrote away the page with the earlier data.

Right.

But I was worrying about the reverse case, that we clear dirty, then
another thread sets it again before we emerge from copy_page_range,
so it gets left behind granting get_user_pages write permission.

Hmm.. At least x86 won't do that - the dirty bits are updated with an 
atomic read-modify-write sequence that only sets the dirty bit. We won't 
get a writable page somehow.

But the lost dirty bit is nasty.

I don't believe there's a safe efficient way we could batch clearing
dirty there. 

Well, there is one really cheap one: look at how many users the VM has.

The thing is, fork() from a threaded environment is simply not done, so we 
could easily have a "slow and careful mode" for the thread case, and 
nobody would probably ever care. 

Whether its worth it, I dunno. It might actually speed up the fork/exit
cases, so it might be worth looking at for that reason.

I'm thinking of reverting to the old __follow_page, setting write_access
-1 in the get_user_pages special case (to avoid change to all the arches,
in some of which write_access is a boolean, in some a bitflag, but in
none -1), and in that write_access -1 case passing back the special
code to say do_wp_page has done its full job.  Combining your and
Nick's and Andrew's ideas, and letting Martin off the hook.
Or would that disgust you too much?  (We could give -1 a pretty name ;)

Go for it, I think whatever we do won't be wonderfully pretty.

		Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>