[lkml]   [2001]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: x86 ptep_get_and_clear question
Manfred Spraul wrote:
> > I can think of one case where performance is considered quite important:
> > mprotect() is used by several garbage collectors, including threaded
> > ones. Maybe mprotect() isn't the best primitive for those anyway, but
> > it's what they have to work with atm.
> Does mprotect() actually care for wrong dirty bits?
> The race should be invisible to user space apps.
> >>>>>>> mprotect()
> for_all_affected_ptes() {
> lock andl ~PERMISSION_MASK, *pte;
> lock orl new_permission, *pte;
> }
> < now anther cpu could still write to the write protected pages
> < and set the dirty bit, but who cares? Shouldn't be a problem.
> flush_tlb_range().
> < tlb flush before ending the syscall, user space can't notice
> < the delay.
> <<<<

The user-space app doesn't even _know_ about dirty bits.

I don't think there's even the possibility of losing dirty bits with
mprotect(), so long as pte_modify doesn't clear the dirty bit, which it
doesn't, in this code:

/* mprotect.c */
entry = ptep_get_and_clear(pte);
set_pte(pte, pte_modify(entry, newprot));

I.e. the only code with the race condition is code which explicitly
clears the dirty bit, in vmscan.c.

Do you see any possibility of losing a dirty bit here?

If not, there's no need for the intricate "gather" or "double scan"
schemes for mprotect() and it can stay as fast as possible.

Btw, a possible mprotect optimisation: there is no need for
flush_tlb_range() when increasing permissions.

-- Jamie
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:15    [W:0.125 / U:1.644 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site