On Tue, 2 Aug 2005, Hugh Dickins wrote:
> >
> > 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
