Jamie wrote "one of my scenarios", that's the other option ;-)
> Now, I will agree that I suspect most x86 _implementations_ will not do
> this. TLB's are too timing-critical, and nobody tends to want to make
> them bigger than necessary - so saving off the source address is
> unlikely. Also, setting the D bit is not a very common operation, so
> it's easy enough to say that an internal D-bit-fault will just cause a
> TLB re-load, where the TLB re-load just sets the A and D bits as it
> fetches the entry (and then page fault handling is an automatic result
> of the reload).
But then the cpu would support setting the D bit in the page directory,
but it doesn't.
Probably Kanoj is right, the current code is not guaranteed by the
But if we change the interface, could we think about the poor s390
s390 only has a "clear the present bit in the pte and flush the tlb"
> pte = ptep_get_and_clear(page_table);
> flush_tlb_page(vma, address);
>+ pte = ptep_update_after_flush(page_table, pte);
What about one arch specific
pte = ptep_get_and_invalidate(vma, address, page_table);
On i386 SMP it would
pte = *page_table_entry;
lock; andl 0xfffffffe, *page_table_entry;
return *page_table_entry | 1;
> The "gather" operation could possibly be improved to make the other
> CPU's do useful work while being shot down (ie schedule away to another
> mm), but that has it's own pitfalls too.
IMHO scheduling away is the best long term solution.
Perhaps try to schedule away, just to improve the probability that
mm->cpu_vm_mask is clear.
I just benchmarked a single flush_tlb_page().
Pentium II 350: ~ 2000 cpu ticks.
Pentium III 850: ~ 3000 cpu ticks.
-- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/