On Wed, May 14, 2008 at 06:26:25AM -0500, Robin Holt wrote:
On Wed, May 14, 2008 at 06:11:22AM +0200, Nick Piggin wrote:
I guess that you have found a way to perform TLB flushing within coherent
domains over the numalink interconnect without sleeping. I'm sure it would
be possible
On Thu, May 15, 2008 at 10:33:57AM -0700, Christoph Lameter wrote:
On Thu, 15 May 2008, Nick Piggin wrote:
Oh, I get that confused because of the mixed up naming conventions
there: unmap_page_range should actually be called zap_page_range. But
at any rate, yes we can easily zap pagetables
On Thursday 08 May 2008 10:38, Robin Holt wrote:
On Wed, May 07, 2008 at 02:36:57PM -0700, Linus Torvalds wrote:
On Wed, 7 May 2008, Andrea Arcangeli wrote:
I think the spinlock-rwsem conversion is ok under config option, as
you can see I complained myself to various of those patches and
On Thursday 08 May 2008 11:34, Andrea Arcangeli wrote:
Sorry for not having completely answered to this. I initially thought
stop_machine could work when you mentioned it, but I don't think it
can even removing xpmem block-inside-mmu-notifier-method requirements.
For stop_machine to solve
On Tue, May 13, 2008 at 10:32:38AM -0500, Robin Holt wrote:
On Tue, May 13, 2008 at 10:06:44PM +1000, Nick Piggin wrote:
On Thursday 08 May 2008 10:38, Robin Holt wrote:
In order to invalidate the remote page table entries, we need to message
(uses XPC) to the remote side. The remote
On Wed, Mar 05, 2008 at 10:48:24AM -0800, Christoph Lameter wrote:
On Wed, 5 Mar 2008, Nick Piggin wrote:
Um, it's bound to the *Linux page tables*, yes. And I have no idea why
you would use the paravirt ops for this.
paravirt ops allows interception of page table operations?
Maybe
On Mon, Mar 03, 2008 at 11:01:22AM -0800, Christoph Lameter wrote:
On Mon, 3 Mar 2008, Nick Piggin wrote:
I'm still not completely happy with this. I had a very quick look
at the GRU driver, but I don't see why it can't be implemented
more like the regular TLB model, and have TLB
On Wednesday 05 March 2008 05:58, Christoph Lameter wrote:
On Tue, 4 Mar 2008, Nick Piggin wrote:
Then put it into the arch code for TLB invalidation. Paravirt ops gives
good examples on how to do that.
Put what into arch code?
The mmu notifier code.
It isn't arch specific
On Mon, Mar 03, 2008 at 01:51:53PM +0100, Andrea Arcangeli wrote:
On Mon, Mar 03, 2008 at 04:29:34AM +0100, Nick Piggin wrote:
to something I prefer. Others may not, but I'll post them for debate
anyway.
Sure, thanks!
I didn't drop invalidate_page, because invalidate_range_begin/end
On Mon, Mar 03, 2008 at 09:18:59AM -0600, Jack Steiner wrote:
On Mon, Mar 03, 2008 at 02:10:17PM +0100, Nick Piggin wrote:
On Mon, Mar 03, 2008 at 01:51:53PM +0100, Andrea Arcangeli wrote:
On Mon, Mar 03, 2008 at 04:29:34AM +0100, Nick Piggin wrote:
to something I prefer. Others may
On Mon, Mar 03, 2008 at 12:06:05PM -0600, Jack Steiner wrote:
On Mon, Mar 03, 2008 at 05:59:10PM +0100, Nick Piggin wrote:
Maintaining a long-term reference on a page is a problem. The GRU does not
currently maintain tables to track the pages for which dropins have been
done
On Sun, Mar 02, 2008 at 04:54:57PM +0100, Andrea Arcangeli wrote:
Difference between #v7 and #v8:
1) s/age_page/clear_flush_young/ (Nick's suggestion)
2) macro fix (Andrew)
3) move release before final unmap_vmas (for GRU, Jack/Christoph)
4) microoptimize mmu_notifier_unregister (Christoph)
mmu_notifier_head in favour of just using the hlist
in mm_struct.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/include/linux/mmu_notifier.h
===
--- linux-2.6.orig/include/linux/mmu_notifier.h
+++ linux-2.6/include/linux
when they
don't make sense.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/include/linux/mmu_notifier.h
===
--- linux-2.6.orig/include/linux/mmu_notifier.h
+++ linux-2.6/include/linux/mmu_notifier.h
@@ -3,8 +3,12
On Sun, Mar 02, 2008 at 04:54:57PM +0100, Andrea Arcangeli wrote:
Difference between #v7 and #v8:
Here is just a couple of checkpatch fixes on top of the last patches.
Index: linux-2.6/include/linux/mmu_notifier.h
===
---
On Thursday 28 February 2008 09:35, Christoph Lameter wrote:
On Wed, 20 Feb 2008, Nick Piggin wrote:
On Friday 15 February 2008 17:49, Christoph Lameter wrote:
Also, what we are going to need here are not skeleton drivers
that just do all the *easy* bits (of registering their callbacks
On Tuesday 26 February 2008 18:21, Gleb Natapov wrote:
On Tue, Feb 26, 2008 at 05:11:32PM +1100, Nick Piggin wrote:
You are missing one point here. The MPI specifications that have
been out there for decades do not require the process use a library
for allocating the buffer. I realize
On Thursday 21 February 2008 21:58, Robin Holt wrote:
On Thu, Feb 21, 2008 at 03:20:02PM +1100, Nick Piggin wrote:
So why can't you export a device from your xpmem driver, which
can be mmap()ed to give out anonymous memory pages to be used
for these communication buffers
On Wednesday 20 February 2008 20:00, Robin Holt wrote:
On Wed, Feb 20, 2008 at 02:51:45PM +1100, Nick Piggin wrote:
On Wednesday 20 February 2008 14:12, Robin Holt wrote:
For XPMEM, we do not currently allow file backed
mapping pages from being exported so we should never reach
On Tue, Feb 19, 2008 at 05:40:50PM -0600, Jack Steiner wrote:
On Wed, Feb 20, 2008 at 12:11:57AM +0100, Nick Piggin wrote:
On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote:
anything when changing the pte
On Wed, Feb 20, 2008 at 02:09:41AM +0100, Andrea Arcangeli wrote:
On Wed, Feb 20, 2008 at 12:11:57AM +0100, Nick Piggin wrote:
Sorry, I realise I still didn't get this through my head yet (and also
have not seen your patch recently). So I don't know exactly what you
are doing...
The last
On Wed, Feb 20, 2008 at 11:39:42AM +0100, Andrea Arcangeli wrote:
Given Nick's comments I ported my version of the mmu notifiers to
latest mainline. There are no known bugs AFIK and it's obviously safe
(nothing is allowed to schedule inside rcu_read_lock taken by
mmu_notifier() with my patch).
On Wed, Feb 20, 2008 at 01:03:24PM +0100, Andrea Arcangeli wrote:
If there's agreement that the VM should alter its locking from
spinlock to mutex for its own good, then Christoph's
one-config-option-fits-all becomes a lot more appealing (replacing RCU
with a mutex in the mmu notifier list
Well I started reviewing the mmu notifier code, but it is kind of hard to
know what you're talking about just by reading through code and not trying
your suggestions for yourself...
So I implemented mmu notifiers slightly differently. Andrea's mmu notifiers
are rather similar. However I have
Index: linux-2.6/drivers/char/mmu_notifier_skel.c
===
--- /dev/null
+++ linux-2.6/drivers/char/mmu_notifier_skel.c
@@ -0,0 +1,255 @@
+#include linux/types.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
On Friday 15 February 2008 17:49, Christoph Lameter wrote:
The invalidation of address ranges in a mm_struct needs to be
performed when pages are removed or permissions etc change.
If invalidate_range_begin() is called with locks held then we
pass a flag into invalidate_range() to indicate
On Friday 15 February 2008 17:49, Christoph Lameter wrote:
The invalidation of address ranges in a mm_struct needs to be
performed when pages are removed or permissions etc change.
If invalidate_range_begin() is called with locks held then we
pass a flag into invalidate_range() to indicate
On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote:
anything when changing the pte to be _more_ permissive, and I don't
Note that in my patch the invalidate_pages in mprotect can be
trivially switched
On Tue, Feb 19, 2008 at 08:27:25AM -0600, Jack Steiner wrote:
On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
understand the need for invalidate_begin/invalidate_end pairs at all.
The need of the pairs is crystal clear to me: range_begin is needed
for GRU
On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote:
are rather similar. However I have tried to make a point of minimising the
impact the the core mm/. I don't see why we need to invalidate or flush
I also tried
On Friday 15 February 2008 17:49, Christoph Lameter wrote:
These special additional callbacks are required because XPmem (and likely
other mechanisms) do use their own rmap (multiple processes on a series
of remote Linux instances may be accessing the memory of a process).
F.e. XPmem may have
On Wednesday 20 February 2008 14:12, Robin Holt wrote:
For XPMEM, we do not currently allow file backed
mapping pages from being exported so we should never reach this condition.
It has been an issue since day 1. We have operated with that assumption
for 6 years and have not had issues with
On Saturday 16 February 2008 14:37, Andrew Morton wrote:
On Thu, 14 Feb 2008 22:49:02 -0800 Christoph Lameter [EMAIL PROTECTED]
wrote:
Two callbacks to remove individual pages as done in rmap code
invalidate_page()
Called from the inner loop of rmap walks to invalidate pages.
On Tuesday 18 September 2007 04:19, Avi Kivity wrote:
Nick Piggin wrote:
I should mention that the converting to use -fault() is a 15-minute
change; the tricky part is adding backwards compatibility for the
external module package.
It should be mostly possible to ifdef a nopage
On Monday 17 September 2007 19:18, Avi Kivity wrote:
Avi Kivity wrote:
Christoph Hellwig wrote:
On Mon, Sep 17, 2007 at 10:30:43AM +0200, Avi Kivity wrote:
From: Nguyen Anh Quynh [EMAIL PROTECTED]
*nopage() in kvm_main.c should only store the type of mmap() fault if
the pointers are
35 matches
Mail list logo
