Daniel J Blueman wrote:
> On 13 Mar, 20:20, Zoltan Menyhart <Zoltan.Menyh...@xxxxxxx> wrote:
>
>> I had a look at copy_one_pte().
>> I cannot see any ioproc_update_page() call, not even for the COW pages.
>> Is it intentional?
>
> There could be an ioproc_update_range() call in
> memory.c:copy_pte_range(), after the pte_unmap_unlock(), and this
> would be an optimisation, since explicitly updating the mappings in
> the Quadrics RDMA NIC avoids the need for the NIC to trap and update
> it's MMU later.
I can agree that this optimization is a good idea.
Can you please confirm that cp->update_range() understands the concept of
the COW? (I.e. the card should not write anything into the COW pages.)
> The code which implements [1] this takes the pagetable locks with
> pte_offset_map_lock(), and uses one of the kmap_atomic slots, so has
> to be after the pagetables are unlocked. The
> ioproc_invalidate_page/range() calls are different and can't live with
> this race, so have to be used with the pagetable locks held.
I can see two issues here:
- Performance problem: page_table_lock is more expensive than a split lock,
and taking page_table_lock after the split lock released is even worse.
- Synchronization problem: do_wp_page() is protected by the appropriate
split lock, i.e. the COW page can be broken up while you are inside
cp->update_range() under the protection of page_table_lock.
I think the PTE modification and the cp->update_xxx() should be protected
by the very same lock, without releasing it between the two operations.
I think the PTE modification and the cp->update_xxx() should be an
atomic operation with respect to the VMM activity.
Thanks,--
Zoltan