Messages in this thread | | | Date | Fri, 16 Feb 2001 15:59:17 +0100 | From | Manfred Spraul <> | Subject | Re: x86 ptep_get_and_clear question |
| |
Jamie Lokier wrote: > > Linus Torvalds wrote: > > So the only case that ends up being fairly heavy may be a case that is > > very uncommon in practice (only for unmapping shared mappings in > > threaded programs or the lazy TLB case). > The lazy tlb case is quite fast: lazy tlb thread never write to user space pages, we don't need to protect the dirty bits. And the first ipi clears mm->cpu_vm_mask, only one ipi. > > 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. <<<<
-- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |