On Tue, Apr 22, 2008 at 09:20:26AM +0200, Andrea Arcangeli wrote:
invalidate_range_start {
spin_lock(kvm-mmu_lock);
kvm-invalidate_range_count++;
rmap-invalidate of sptes in range
write_seqlock; write_sequnlock;
spin_unlock(kvm-mmu_lock)
}
On Tue, Apr 22, 2008 at 02:00:56PM +0200, Andrea Arcangeli wrote:
On Tue, Apr 22, 2008 at 09:20:26AM +0200, Andrea Arcangeli wrote:
invalidate_range_start {
spin_lock(kvm-mmu_lock);
kvm-invalidate_range_count++;
rmap-invalidate of sptes in range
On Tue, Apr 22, 2008 at 08:01:20AM -0500, Robin Holt wrote:
On Tue, Apr 22, 2008 at 02:00:56PM +0200, Andrea Arcangeli wrote:
On Tue, Apr 22, 2008 at 09:20:26AM +0200, Andrea Arcangeli wrote:
invalidate_range_start {
spin_lock(kvm-mmu_lock);
kvm-invalidate_range_count++;
On Tue, Apr 22, 2008 at 03:21:43PM +0200, Andrea Arcangeli wrote:
On Tue, Apr 22, 2008 at 08:01:20AM -0500, Robin Holt wrote:
On Tue, Apr 22, 2008 at 02:00:56PM +0200, Andrea Arcangeli wrote:
On Tue, Apr 22, 2008 at 09:20:26AM +0200, Andrea Arcangeli wrote:
invalidate_range_start {
On Tue, Apr 22, 2008 at 08:36:04AM -0500, Robin Holt wrote:
I am a little confused about the value of the seq_lock versus a simple
atomic, but I assumed there is a reason and left it at that.
There's no value for anything but get_user_pages (get_user_pages takes
its own lock internally though).
Andrew, Could we get direction/guidance from you as regards
the invalidate_page() callout of Andrea's patch set versus the
invalidate_range_start/invalidate_range_end callout pairs of Christoph's
patchset? This is only in the context of the __xip_unmap, do_wp_page,
page_mkclean_one, and
On Tue, 8 Apr 2008, Andrea Arcangeli wrote:
The difference with #v11 is a different implementation of mm_lock that
guarantees handling signals in O(N). It's also more lowlatency friendly.
Ok. So the rest of the issues remains unaddressed? I am glad that we
finally settled on the locking. But
I applied this patch set with the xpmem version I am working up for
submission and the basic level-1 and level-2 tests passed. The full mpi
regression test still tends to hang, but that appears to be a common
problem failure affecting either emm or mmu notifiers and therefore, I
am certain is a
The difference with #v11 is a different implementation of mm_lock that
guarantees handling signals in O(N). It's also more lowlatency friendly.
Note that mmu_notifier_unregister may also fail with -EINTR if there are
signal pending or the system runs out of vmalloc space or physical memory,
only
Andrea Arcangeli wrote:
Note that mmu_notifier_unregister may also fail with -EINTR if there are
signal pending or the system runs out of vmalloc space or physical memory,
only exit_mmap guarantees that any kernel module can be unloaded in presence
of an oom condition.
That's unusual.
On Wed, Apr 09, 2008 at 12:46:49AM +0300, Avi Kivity wrote:
That's unusual. What happens to the notifier? Suppose I destroy a vm
Yes it's quite unusual.
without exiting the process, what happens if it fires?
The mmu notifier ops should stop doing stuff (if there will be no
memslots they
11 matches
Mail list logo
