David Rientjes wrote:
On Sun, 25 Mar 2007, Zachary Amsden wrote:
If you actually clear the bit, you need to:
+ pte_update_defer(vma->vm_mm, addr, ptep);
The reason is, when updating PTEs, the hypervisor must be notified. Using
atomic operations to do this is fine for all hyperviso
Hugh Dickins wrote:
On Sun, 25 Mar 2007, Zachary Amsden wrote:
If you actually clear the bit, you need to:
+ pte_update_defer(vma->vm_mm, addr, ptep);
The reason is, when updating PTEs, the hypervisor must be notified. Using
atomic operations to do this is fine for all hypervisors
On Sun, 25 Mar 2007, Zachary Amsden wrote:
> If you actually clear the bit, you need to:
>
> + pte_update_defer(vma->vm_mm, addr, ptep);
>
> The reason is, when updating PTEs, the hypervisor must be notified. Using
> atomic operations to do this is fine for all hypervisors I am aware of
On Sun, 25 Mar 2007, Zachary Amsden wrote:
>
> If you actually clear the bit, you need to:
>
> + pte_update_defer(vma->vm_mm, addr, ptep);
>
> The reason is, when updating PTEs, the hypervisor must be notified. Using
> atomic operations to do this is fine for all hypervisors I am aware
Hugh Dickins wrote:
On Sun, 25 Mar 2007, David Rientjes wrote:
Add ptep_test_and_clear_{dirty,young} to i386. They advertise that they
have it and there is at least one place where it needs to be called
without the page table lock: to clear the accessed bit on write to
Without the pag
On Sun, 25 Mar 2007, David Rientjes wrote:
> Add ptep_test_and_clear_{dirty,young} to i386. They advertise that they
> have it and there is at least one place where it needs to be called
> without the page table lock: to clear the accessed bit on write to
Without the page table lock??
> /proc/pi
Add ptep_test_and_clear_{dirty,young} to i386. They advertise that they
have it and there is at least one place where it needs to be called
without the page table lock: to clear the accessed bit on write to
/proc/pid/clear_refs.
ptep_clear_flush_{dirty,young} are updated to use the new functions.
7 matches
Mail list logo
