>>> Andi Kleen <[email protected]> 30.04.07 17:50 >>>
>
>From: Zachary Amsden <[email protected]>
>
>In situations where page table updates need only be made locally, and there is
>no cross-processor A/D bit races involved, we need not use the heavyweight
>xchg instruction to atomically fetch and clear page table entries. Instead,
>we can just read and clear them directly.
I always wondered why the xchg is necessary here at all. If the process of
tearing down a page table entry has started, other users of the mapped
linear address are broken anyway - why is it necessary to still monitor the
effect they may have on the A/D bits, unless this is a transient tear down?
Checking for the uses of ptep_get_and_clear, I would judge that the use in
change_pte_range() may in fact need the xchg, but the uses in
vunmap_pte_range() and zap_pte_range() shouldn't.
Jan
> I always wondered why the xchg is necessary here at all. If the process of
> tearing down a page table entry has started, other users of the mapped
> linear address are broken anyway - why is it necessary to still monitor the
> effect they may have on the A/D bits, unless this is a transient tear down?
>
> Checking for the uses of ptep_get_and_clear, I would judge that the use in
> change_pte_range() may in fact need the xchg, but the uses in
> vunmap_pte_range() and zap_pte_range() shouldn't.
Yes I agree. Might be a nice speed up for exit to distingush the cases.
-Andi
Andi Kleen wrote:
>> I always wondered why the xchg is necessary here at all. If the process of
>> tearing down a page table entry has started, other users of the mapped
>> linear address are broken anyway - why is it necessary to still monitor the
>> effect they may have on the A/D bits, unless this is a transient tear down?
>>
>> Checking for the uses of ptep_get_and_clear, I would judge that the use in
>> change_pte_range() may in fact need the xchg, but the uses in
>> vunmap_pte_range() and zap_pte_range() shouldn't.
>>
>
> Yes I agree. Might be a nice speed up for exit to distingush the cases.
>
That is what I did in this patch - but with care zap_pte_range can also
be called in non-teardown cases when unmapping (when !fullmm) and user
mappings could still be in effect on remote processors.
Zach