[<prev] [next>] [day] [month] [year] [list]
Message-ID: <6278d2220704020917h69d7c0d1t7ac61a544ec23f4@mail.gmail.com>
Date: Mon, 2 Apr 2007 17:17:48 +0100
From: "Daniel J Blueman" <daniel.blueman@...il.com>
To: "Zoltan Menyhart" <Zoltan.Menyhart@...l.net>
Cc: "Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: copy_one_pte()
On 13 Mar, 20:20, Zoltan Menyhart <Zoltan.Menyh...@...e.fr> 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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists