On 06/03/2010 11:11 AM, Andrew Morton wrote:
On Thu, 3 Jun 2010 10:36:00 -0700
Doug Doan<dougd@xxxxxxxx> wrote:
Well, specifically it means that
mmu_notifier_invalidate_range_start/end() implemetnations can no longer
take page_table_lock or any lock which nests outside page_table_lock.
That lessens flexibility.
As the other mmu_notifier_invalidate_range_start/end() callsite in this
function carefully nested those calls outside page_table_lock, perhaps
that was thought to be a significant thing.
Here's my rationale: for the normal page case, the invalidation call is done
inside a page_table_lock,
It is? Where does that happen?
handle_pte_fault() acquires the lock before calling do_wp_page():
ptl = pte_lockptr(mm, pmd);
spin_lock(ptl);
if (unlikely(!pte_same(*pte, entry)))
goto unlock;
if (flags & FAULT_FLAG_WRITE) {
if (!pte_write(entry))
return do_wp_page(mm, vma, address,
pte, pmd, ptl, entry);
entry = pte_mkdirty(entry);
}
do_wp_page() calls set_pte_at_notify(), which either calls
mmu_notifier_change_pte() or mmu_notifier_invalidate_page().
so the same should also be done in the huge page case.
Does it really make sense to call invalidation on one hugepage and have another
call invalidate the same hugepage while the first call is still not finished?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>