RE: [patch] arch hook for notifying changes in PTE protections bits

2005-03-20 Thread Seth, Rohit
David S. Miller wrote on Saturday, March 19, 2005 4:27 PM: > On Sat, 19 Mar 2005 12:30:05 -0800 > David Mosberger <[EMAIL PROTECTED]> wrote: > >> I agree about your concern about cost. Accessing the page_map is >> expensive (integer division + memory access) and we hav

Re: [patch] arch hook for notifying changes in PTE protections bits

2005-03-19 Thread David S. Miller
On Sat, 19 Mar 2005 12:30:05 -0800 David Mosberger <[EMAIL PROTECTED]> wrote: > I agree about your concern about cost. Accessing the page_map is > expensive (integer division + memory access) and we have to do that in > order to find out if the page is i-cache clean. First, it's a multiply by re

RE: [patch] arch hook for notifying changes in PTE protections bits

2005-03-19 Thread David Mosberger
> On Sat, 19 Mar 2005 12:22:20 -0800, "Seth, Rohit" <[EMAIL PROTECTED]> > said: Rohit> David S. Miller wrote on Friday, Rohit> March 18, 2005 8:06 PM: >> Take a look at set_pte_at(). You get the "mm", the virtual >> address, the pte pointer, and the n

RE: [patch] arch hook for notifying changes in PTE protections bits

2005-03-19 Thread Seth, Rohit
David S. Miller wrote on Friday, March 18, 2005 8:06 PM: > > Take a look at set_pte_at(). You get the "mm", the > virtual address, the pte pointer, and the new pte value. > Thanks for pointing out the updated interface in 2.6.12-* kernel. I think I can overload the

Re: [patch] arch hook for notifying changes in PTE protections bits

2005-03-18 Thread David S. Miller
This is way overkill I think. Take a look at set_pte_at(). You get the "mm", the virtual address, the pte pointer, and the new pte value. What else could you possibly need to track stuff like this and react appropriately? :-) It is even an argument for batched TLB processing on ia64. It simpli