On Thu, Jan 17, 2008 at 08:21:16PM +0200, Izik Eidus wrote:
> ohh i like it, this is cleaver solution, and i guess the cost of the
> vmexits wont be too high if it will
> be not too much aggressive
Yes, and especially during swapping, the system isn't usually CPU
bound. The idea is to pay wit
Andrea Arcangeli wrote:
On Wed, Jan 16, 2008 at 07:48:06PM +0200, Izik Eidus wrote:
Rik van Riel wrote:
On Sun, 13 Jan 2008 17:24:18 +0100
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
In my basic initial patch I only track the tlb flushes which should be
the minimum required
On Wed, Jan 16, 2008 at 07:48:06PM +0200, Izik Eidus wrote:
> Rik van Riel wrote:
>> On Sun, 13 Jan 2008 17:24:18 +0100
>> Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>>
>>
>>> In my basic initial patch I only track the tlb flushes which should be
>>> the minimum required to have a nice linux-VM
Rik van Riel wrote:
On Sun, 13 Jan 2008 17:24:18 +0100
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
In my basic initial patch I only track the tlb flushes which should be
the minimum required to have a nice linux-VM controlled swapping
behavior of the KVM gphysical memory.
I have a va
On Sun, 13 Jan 2008 17:24:18 +0100
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
> In my basic initial patch I only track the tlb flushes which should be
> the minimum required to have a nice linux-VM controlled swapping
> behavior of the KVM gphysical memory.
I have a vaguely related question on
On Wed, Jan 16, 2008 at 10:01:32AM +0100, Brice Goglin wrote:
> One of the difference with my patch is that you attach the notifier list to
> the mm_struct while my code attached it to vmas. But I now don't think it
> was such a good idea since it probably didn't reduce the number of notifier
>
Andrea Arcangeli wrote:
This patch is last version of a basic implementation of the mmu
notifiers.
In short when the linux VM decides to free a page, it will unmap it
from the linux pagetables. However when a page is mapped not just by
the regular linux ptes, but also from the shadow pagetables,
On Wed, Jan 16, 2008 at 07:18:53AM +1100, Benjamin Herrenschmidt wrote:
> Do you have cases where it's -not- called with the PTE lock held ?
For invalidate_page no because currently it's only called next to the
ptep_get_and_clear that modifies the pte and requires the pte
lock. invalidate_range/re
On Tue, 2008-01-15 at 13:44 +0100, Andrea Arcangeli wrote:
> On Mon, Jan 14, 2008 at 12:02:42PM -0800, Christoph Lameter wrote:
> > Hmmm... In most of the callsites we hold a writelock on mmap_sem right?
>
> Not in all, like Marcelo pointed out in kvm-devel, so the lowlevel
> locking can't relay
On Mon, Jan 14, 2008 at 12:02:42PM -0800, Christoph Lameter wrote:
> Hmmm... In most of the callsites we hold a writelock on mmap_sem right?
Not in all, like Marcelo pointed out in kvm-devel, so the lowlevel
locking can't relay on the VM locks.
About your request to schedule in the mmu notifier m
On Mon, 2008-01-14 at 12:02 -0800, Christoph Lameter wrote:
> On Sun, 13 Jan 2008, Andrea Arcangeli wrote:
>
> > About the locking perhaps I'm underestimating it, but by following the
> > TLB flushing analogy, by simply clearing the shadow ptes (with kvm
> > mmu_lock spinlock to avoid racing with
On Sun, 13 Jan 2008, Andrea Arcangeli wrote:
> About the locking perhaps I'm underestimating it, but by following the
> TLB flushing analogy, by simply clearing the shadow ptes (with kvm
> mmu_lock spinlock to avoid racing with other vcpu spte accesses of
> course) and flushing the shadow-pte afte
On Sun, 2008-01-13 at 17:24 +0100, Andrea Arcangeli wrote:
> Hello,
>
> This patch is last version of a basic implementation of the mmu
> notifiers.
>
> In short when the linux VM decides to free a page, it will unmap it
> from the linux pagetables. However when a page is mapped not just by
> th
13 matches
Mail list logo
