On 13 Mar, 20:20, Zoltan Menyhart <[EMAIL PROTECTED]> 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. 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. Daniel --- [1] http://lwn.net/Articles/133627/ http://www.quadrics.com/linux
We can live with a COW page for a considerably long time. How could the IO-PROC. know that a process-ID / user virt. addr. pair refers to the same page? The comment above ioproc_update_page() says that every time when a PTE is created / modified... Thanks, ZoltanMenyhart
-- Daniel J Blueman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
