On Fri, May 16, 2008 at 01:52:03AM +0200, Nick Piggin wrote:
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
On Fri, May 16, 2008 at 06:23:06AM -0500, Robin Holt wrote:
On Fri, May 16, 2008 at 01:52:03AM +0200, Nick Piggin wrote:
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
We are pursuing Linus' suggestion currently. This discussion is
completely unrelated to that work.
On Thu, May 15, 2008 at 09:57:47AM +0200, Nick Piggin wrote:
I'm not sure if you're thinking about what I'm thinking of. With the
scheme I'm imagining, all you will need is some way to raise an
On Wed, May 14, 2008 at 06:11:22AM +0200, Nick Piggin wrote:
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
On Wed, May 14, 2008 at 08:18:21AM -0700, Linus Torvalds wrote:
On Wed, 14 May 2008, Robin Holt wrote:
Are you suggesting the sending side would not need to sleep or the
receiving side?
One thing to realize is that most of the time (read: pretty much *always*)
when we have the problem
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 side needs to acquire the
importing process's mmap_sem and call
You can drop this patch.
This turned out to be a race in xpmem. It appeared as if it were a
race in get_task_mm, but it really is not. The current-mm field is
cleared under the task_lock and the task_lock is grabbed by get_task_mm.
I have been testing you v15 version without this patch and not
are in the process of getting XPMEM working
on x86_64 cross-partition in support of UV.
Thanks,
Robin Holt
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time
simple.
Also, stop-machine will not work if we come to the conclusion that
i_mmap_lock and anon_vma-lock need to be sleepable locks.
Thanks,
Robin Holt
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't
diff --git a/mm/Kconfig b/mm/Kconfig
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -205,3 +205,6 @@ config VIRT_TO_BUS
config VIRT_TO_BUS
def_bool y
depends on !ARCH_NO_VIRT_TO_BUS
+
+config MMU_NOTIFIER
+ bool
Without some text following the bool keyword, I am not even asked
On Mon, May 05, 2008 at 12:08:25AM +0200, Andrea Arcangeli wrote:
On Sun, May 04, 2008 at 02:13:45PM -0500, Robin Holt wrote:
diff --git a/mm/Kconfig b/mm/Kconfig
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -205,3 +205,6 @@ config VIRT_TO_BUS
config VIRT_TO_BUS
def_bool y
I however doubt this will bring us back to the same performance of the
current spinlock version, as the real overhead should come out of
overscheduling in down_write ai anon_vma_link. Here an initially
spinning lock would help but that's gray area, it greatly depends on
timings, and on very
On Thu, Apr 24, 2008 at 07:41:45PM +0200, Andrea Arcangeli wrote:
A full new update will some become visible here:
http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.25/mmu-notifier-v14-pre3/
I grabbed these and built them. Only change needed was another include.
On Fri, Apr 25, 2008 at 06:56:40PM +0200, Andrea Arcangeli wrote:
Fortunately I figured out we don't really need mm_lock in unregister
because it's ok to unregister in the middle of the range_begin/end
critical section (that's definitely not ok for register that's why
register needs mm_lock).
I am not certain of this, but it seems like this patch leaves things in
a somewhat asymetric state. At the very least, I think that asymetry
should be documented in the comments of either mmu_notifier.h or .c.
Before I do the first mmu_notifier_register, all places that test for
On Wed, Apr 23, 2008 at 03:36:19PM +0200, Andrea Arcangeli wrote:
On Tue, Apr 22, 2008 at 06:07:27PM -0500, Robin Holt wrote:
The only other change I did has been to move mmu_notifier_unregister
at the end of the patchset after getting more questions about its
reliability and I
On Wed, Apr 23, 2008 at 03:44:27PM +0200, Andrea Arcangeli wrote:
On Tue, Apr 22, 2008 at 04:14:26PM -0700, Christoph Lameter wrote:
We want a full solution and this kind of patching makes the patches
difficuilt to review because later patches revert earlier ones.
I know you rather want
On Wed, Apr 23, 2008 at 06:15:45PM +0200, Andrea Arcangeli wrote:
Once I get confirmation that everyone is ok with #v13 I'll push a #v14
before Saturday with that cosmetical error cleaned up and
mmu_notifier_unregister moved at the end (XPMEM will have unregister
don't worry). I expect the
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 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
, and try_to_unmap_one call sites.
On Tue, Apr 22, 2008 at 03:48:47PM +0200, Andrea Arcangeli wrote:
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
acceptable.
Can we agree upon this list of issues?
Thank you,
Robin Holt
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority
On Tue, Apr 22, 2008 at 08:43:35PM +0200, Andrea Arcangeli wrote:
On Tue, Apr 22, 2008 at 01:22:13PM -0500, Robin Holt wrote:
1) invalidate_page: You retain an invalidate_page() callout. I believe
we have progressed that discussion to the point that it requires some
direction for Andrew
On Tue, Apr 22, 2008 at 01:19:29PM -0700, Christoph Lameter wrote:
Thanks for adding most of my enhancements. But
1. There is no real need for invalidate_page(). Can be done with
invalidate_start/end. Needlessly complicates the API. One
of the objections by Andrew was that there
The only other change I did has been to move mmu_notifier_unregister
at the end of the patchset after getting more questions about its
reliability and I documented a bit the rmmod requirements for
-release. we'll think later if it makes sense to add it, nobody's
using it anyway.
XPMEM is
On Wed, Apr 23, 2008 at 12:43:52AM +0200, Andrea Arcangeli wrote:
On Tue, Apr 22, 2008 at 01:22:55PM -0700, Christoph Lameter wrote:
Looks like this is not complete. There are numerous .h files missing which
means that various structs are undefined (fs.h and rmap.h are needed
f.e.) which
On Wed, Apr 16, 2008 at 12:15:08PM -0700, Christoph Lameter wrote:
On Wed, 16 Apr 2008, Robin Holt wrote:
On Wed, Apr 16, 2008 at 11:35:38AM -0700, Christoph Lameter wrote:
On Wed, 16 Apr 2008, Robin Holt wrote:
I don't think this lock mechanism is completely working. I have
On Thu, Apr 17, 2008 at 05:51:57PM +0200, Andrea Arcangeli wrote:
On Wed, Apr 16, 2008 at 11:35:38AM -0700, Christoph Lameter wrote:
On Wed, 16 Apr 2008, Robin Holt wrote:
I don't think this lock mechanism is completely working. I have
gotten a few failures trying to dereference
On Thu, Apr 17, 2008 at 07:14:43PM +0200, Andrea Arcangeli wrote:
On Thu, Apr 17, 2008 at 11:36:42AM -0500, Robin Holt wrote:
In this case, we are not making the call to unregister, we are waiting
for the _release callout which has already removed it from the list.
In the event
I don't think this lock mechanism is completely working. I have
gotten a few failures trying to dereference 0x100100 which appears to
be LIST_POISON1.
Thanks,
Robin
-
This SF.net email is sponsored by the 2008 JavaOne(SM)
On Wed, Apr 16, 2008 at 11:35:38AM -0700, Christoph Lameter wrote:
On Wed, 16 Apr 2008, Robin Holt wrote:
I don't think this lock mechanism is completely working. I have
gotten a few failures trying to dereference 0x100100 which appears to
be LIST_POISON1.
How does xpmem unregistering
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
This one does not build on ia64. I get the following:
[EMAIL PROTECTED] mmu_v12_xpmem_v003_v1]$ make compressed
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALLscripts/checksyscalls.sh
CHK include/linux/compile.h
CC mm/mmu_notifier.o
In file included
On Wed, Apr 02, 2008 at 08:49:52AM +0200, Andrea Arcangeli wrote:
Most other patches will apply cleanly on top of my coming mmu
notifiers #v10 that I hope will go in -mm.
For #v10 the only two left open issues to discuss are:
Does your v10 allow sleeping inside the callbacks?
Thanks,
Robin
Arcangeli wrote:
On Wed, Apr 02, 2008 at 05:59:25AM -0500, Robin Holt wrote:
On Wed, Apr 02, 2008 at 08:49:52AM +0200, Andrea Arcangeli wrote:
Most other patches will apply cleanly on top of my coming mmu
notifiers #v10 that I hope will go in -mm.
For #v10 the only two left open
On Wed, Mar 05, 2008 at 07:09:55AM +0200, Avi Kivity wrote:
Isn't that out of the question for .25?
I keep hearing this mantra. What is so compelling about the .25
release? When seems to be more important than what. While I understand
product release cycles, etc. and can certainly agree with
On Thu, Feb 28, 2008 at 01:52:50AM +0100, Andrea Arcangeli wrote:
On Wed, Feb 27, 2008 at 04:14:08PM -0800, Christoph Lameter wrote:
Erm. This would also be needed by RDMA etc.
The only RDMA I know is Quadrics, and Quadrics apparently doesn't need
to schedule inside the invalidate methods
On Tue, Feb 26, 2008 at 07:52:41PM +1100, Nick Piggin wrote:
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
That is it. That is all our allowed interaction with the users process.
OK, when you said something along the lines of the MPT library has
control of the comm buffer, then I assumed it was an area of virtual
memory which is set up as part of initialization, rather than during
runtime. I
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?
Because we need to have heap and stack available as well. MPT
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 this condition.
It has been an issue since day 1. We have operated
On Wed, Feb 20, 2008 at 03:00:36AM -0600, 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 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:
I'm unconvinced both the main linux VM and the mmu notifier should be
changed like this just to support xpmem. All non-sleeping users don't
need that. Nevertheless I'm fully welcome to support xpmem (and it's
not my call nor my
On Wed, Feb 20, 2008 at 01:32:36PM +0100, Andrea Arcangeli wrote:
On Wed, Feb 20, 2008 at 06:24:24AM -0600, Robin Holt wrote:
We do not need to do any allocation in the messaging layer, all
structures used for messaging are allocated at module load time.
The allocation discussions we had
On Wed, Feb 20, 2008 at 11:39:42AM +0100, Andrea Arcangeli wrote:
XPMEM simply can't use RCU for the registration locking if it wants to
schedule inside the mmu notifier calls. So I guess it's better to add
Whoa there. In Christoph's patch, we did not use rcu for the list. It
was a simple
On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote:
So I implemented mmu notifiers slightly differently. Andrea's mmu notifiers
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
anything
On Wed, Feb 20, 2008 at 01:52:06AM +0100, Andrea Arcangeli wrote:
On Wed, Feb 20, 2008 at 12:04:27AM +0100, Nick Piggin wrote:
OK (thanks to Robin as well). Now I understand why you are using it,
but I don't understand why you don't defer new TLBs after the point
where the linux pte
On Wed, Feb 20, 2008 at 10:55:20AM +1100, Nick Piggin wrote:
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
On Wed, Feb 20, 2008 at 02:11:41PM +1100, Nick Piggin wrote:
On Wednesday 20 February 2008 14:00, Robin Holt wrote:
On Wed, Feb 20, 2008 at 02:00:38AM +0100, Andrea Arcangeli wrote:
On Wed, Feb 20, 2008 at 10:08:49AM +1100, Nick Piggin wrote:
Also, how to you resolve the case where you
On Sun, Feb 17, 2008 at 04:01:20AM +0100, Andrea Arcangeli wrote:
On Sat, Feb 16, 2008 at 11:21:07AM -0800, Christoph Lameter wrote:
On Fri, 15 Feb 2008, Andrew Morton wrote:
What is the status of getting infiniband to use this facility?
Well we are talking about this it seems.
It
On Sat, Feb 16, 2008 at 11:48:27AM +0100, Andrea Arcangeli wrote:
Those below two patches enable KVM to swap the guest physical memory
through Christoph's V7.
There's one last _purely_theoretical_ race condition I figured out and
that I'm wondering how to best fix. The race condition worst
On Fri, Feb 08, 2008 at 03:32:19PM -0800, Christoph Lameter wrote:
On Fri, 8 Feb 2008, Andrew Morton wrote:
What about ib_umem_get()?
Ok. It pins using an elevated refcount. Same as XPmem right now. With that
we effectively pin a page (page migration will fail) but we will
continually
On Fri, Feb 08, 2008 at 03:41:24PM -0800, Christoph Lameter wrote:
On Fri, 8 Feb 2008, Robin Holt wrote:
What about ib_umem_get()?
Correct.
You missed the turn of the conversation to how ib_umem_get() works.
Currently it seems to pin the same way that the SLES10 XPmem works.
Ah. I
On Tue, Feb 05, 2008 at 02:06:23PM -0800, Christoph Lameter wrote:
On Tue, 5 Feb 2008, Andrea Arcangeli wrote:
On Tue, Feb 05, 2008 at 10:17:41AM -0800, Christoph Lameter wrote:
The other approach will not have any remote ptes at that point. Why would
there be a coherency issue?
On Fri, Feb 01, 2008 at 04:32:21AM -0600, Robin Holt wrote:
On Thu, Jan 31, 2008 at 08:43:58PM -0800, Christoph Lameter wrote:
On Thu, 31 Jan 2008, Robin Holt wrote:
Index: linux-2.6/mm/memory.c
...
@@ -1668,6 +1678,7 @@ gotten:
page_cache_release(old_page
On Thu, Jan 31, 2008 at 08:43:58PM -0800, Christoph Lameter wrote:
On Thu, 31 Jan 2008, Robin Holt wrote:
Index: linux-2.6/mm/memory.c
...
@@ -1668,6 +1678,7 @@ gotten:
page_cache_release(old_page);
unlock:
pte_unmap_unlock(page_table, ptl);
+ mmu_notifier
OK. Now that release has been moved, I think I agree with you that the
down_write(mmap_sem) can be used as our lock again and still work for
Jack. I would like a ruling from Jack as well.
Thanks,
Robin
-
This SF.net email
On Fri, Feb 01, 2008 at 04:55:16AM -0600, Robin Holt wrote:
OK. Now that release has been moved, I think I agree with you that the
down_write(mmap_sem) can be used as our lock again and still work for
Jack. I would like a ruling from Jack as well.
Ignore this, I was in the wrong work area
With this set of patches, I think we have enough to get xpmem working
with most types of mappings. In the past, we operated without any of
these callouts by significantly restricting why types of mappings could
remotely fault and what types of operations the user could do. With
this set, I am
Argh,
Here is the correct one. Sorry
On Fri, Feb 01, 2008 at 05:58:41AM -0600, Robin Holt wrote:
With this set of patches, I think we have enough to get xpmem working
with most types of mappings. In the past, we operated without any of
these callouts by significantly restricting why types
Christoph,
The following code in do_wp_page is a problem.
We are getting this callout when we transition the pte from a read-only
to read-write. Jack and I can not see a reason we would need that
callout. It is causing problems for xpmem in that a write fault goes
to get_user_pages which gets
On Fri, Feb 01, 2008 at 04:05:08PM -0800, Christoph Lameter wrote:
On Fri, 1 Feb 2008, Robin Holt wrote:
On Fri, Feb 01, 2008 at 03:19:32PM -0800, Christoph Lameter wrote:
On Fri, 1 Feb 2008, Robin Holt wrote:
We are getting this callout when we transition the pte from a read-only
On Fri, Feb 01, 2008 at 06:21:45PM -0600, Robin Holt wrote:
On Fri, Feb 01, 2008 at 04:05:08PM -0800, Christoph Lameter wrote:
Are you saying that you get the callback when transitioning from a read
only to a read write pte on the *same* page?
I believe that is what we saw. We have
On Thu, Jan 31, 2008 at 05:37:21PM -0800, Christoph Lameter wrote:
On Fri, 1 Feb 2008, Andrea Arcangeli wrote:
I appreciate the review! I hope my entirely bug free and
strightforward #v5 will strongly increase the probability of getting
this in sooner than later. If something else it
On Thu, Jan 31, 2008 at 07:56:12PM -0600, Jack Steiner wrote:
@@ -2033,6 +2034,7 @@ void exit_mmap(struct mm_struct *mm)
unsigned long end;
/* mm's last user has gone, and its about to be pulled down */
+ mmu_notifier(invalidate_all, mm, 0);
arch_exit_mmap(mm);
On Thu, Jan 31, 2008 at 05:57:25PM -0800, Christoph Lameter wrote:
Move page tables also needs to invalidate the external references
and hold new references off while moving page table entries.
I must admit to not having spent any time thinking about this, but aren't
we moving the entries from
On Thu, Jan 31, 2008 at 06:39:19PM -0800, Christoph Lameter wrote:
On Thu, 31 Jan 2008, Robin Holt wrote:
Jack has repeatedly pointed out needing an unregister outside the
mmap_sem. I still don't see the benefit to not having the lock in the mm.
I never understood why this would
Index: linux-2.6/include/linux/mmu_notifier.h
...
+struct mmu_notifier_ops {
...
+ /*
+ * invalidate_range_begin() and invalidate_range_end() must paired.
+ * Multiple invalidate_range_begin/ends may be nested or called
+ * concurrently. That is legit. However, no new
On Thu, Jan 31, 2008 at 07:58:40PM -0800, Christoph Lameter wrote:
On Thu, 31 Jan 2008, Robin Holt wrote:
+ void (*invalidate_range_end)(struct mmu_notifier *mn,
+ struct mm_struct *mm, int atomic);
I think we need to pass in the same start-end here as well
Robin, if you don't mind, could you please post or upload somewhere
your GPLv2 code that registers itself in Christoph's V2 notifiers? Or
is it top secret? I wouldn't mind to have a look so I can better
understand what's the exact reason you're sleeping besides attempting
GFP_KERNEL
On Wed, Jan 30, 2008 at 06:04:52PM +0100, Andrea Arcangeli wrote:
On Wed, Jan 30, 2008 at 10:11:24AM -0600, Robin Holt wrote:
...
The three issues we need to simultaneously solve is revoking the remote
page table/tlb information while still in a sleepable context and not
having the remote
Back to one of Andrea's points from a couple days ago, I think we still
have a problem with the PageExternalRmap page flag.
If I had two drivers with external rmap implementations, there is no way
I can think of for a simple flag to coordinate a single page being
exported and maintained by the
This is the second part of a patch posted to patch 1/6.
Index: git-linus/mm/rmap.c
===
--- git-linus.orig/mm/rmap.c2008-01-30 11:55:56.0 -0600
+++ git-linus/mm/rmap.c 2008-01-30 12:01:28.0 -0600
@@ -476,8 +476,10
On Wed, Jan 30, 2008 at 11:50:26AM -0800, Christoph Lameter wrote:
On Wed, 30 Jan 2008, Andrea Arcangeli wrote:
XPMEM requires with invalidate_range (sleepy) +
before_invalidate_range (sleepy). invalidate_all should also be called
before_release (both sleepy).
It sounds we need full
Well the GRU uses follow_page() instead of get_user_pages. Performance is
a major issue for the GRU.
Worse, the GRU takes its TLB faults from within an interrupt so we
use follow_page to prevent going to sleep. That said, I think we
could probably use follow_page() with FOLL_GET set to
I am going to seperate my comments into individual replies to help
reduce the chance they are lost.
+void mmu_notifier_release(struct mm_struct *mm)
...
+ hlist_for_each_entry_safe_rcu(mn, n, t,
+ mm-mmu_notifier.head, hlist) {
+
What is the status of getting invalidate_all adjusted to indicate a need
to also call _release?
Thanks,
Robin
On Mon, Jan 28, 2008 at 12:28:46PM -0800, Christoph Lameter wrote:
when a task exits we can remove all external pts at once. At that point the
extern mmu may also unregister itself
I don't understand how this is intended to work. I think the page flag
needs to be maintained by the mmu_notifier subsystem.
Let's assume we have a mapping that has a grant from xpmem and an
additional grant from kvm. The exporters are not important, the fact
that there may be two is.
Assume
+void mmu_notifier_release(struct mm_struct *mm)
...
+ hlist_for_each_entry_safe_rcu(mn, n, t,
+ mm-mmu_notifier.head, hlist) {
+ if (mn-ops-release)
+ mn-ops-release(mn, mm);
+
void mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm)
{
- spin_lock(mmu_notifier_list_lock);
- hlist_add_head(mn-hlist, mm-mmu_notifier.head);
- spin_unlock(mmu_notifier_list_lock);
+ down_write(mm-mmap_sem);
+ __mmu_notifier_register(mn, mm);
+
1. invalidate_all()
That will be fine as long as we can unregister the ops notifier and free
the structure. Otherwise, we end up being called needlessly.
No you cannot do that because there are still callbacks that come later.
The invalidate_all may lead to invalidate_range() doing
On Fri, Jan 25, 2008 at 11:03:07AM -0800, Christoph Lameter wrote:
Shouldn't this really be protected by the down_write(mmap_sem)? Maybe:
Ok. We could switch this to mmap_sem protection for the mm_struct but the
rmap notifier is not associated with an mm_struct. So we would need to
On Fri, Jan 25, 2008 at 12:42:29PM +0100, Andrea Arcangeli wrote:
On a technical merit this still partially makes me sick and I think
it's the last issue to debate.
@@ -971,6 +974,9 @@ int try_to_unmap(struct page *page, int
else
ret = try_to_unmap_file(page,
+#define mmu_notifier(function, mm, args...) \
...
+ if (__mn-ops-function)\
+ __mn-ops-function(__mn, \
+ mm, \
+
On Fri, Jan 25, 2008 at 10:47:04AM -0800, Christoph Lameter wrote:
On Fri, 25 Jan 2008, Robin Holt wrote:
I realize it is a minor nit, but since we put the continuation in column
81 in the next define, can we do the same here and make this more
readable?
We need to fix the next define
On Wed, Jan 23, 2008 at 12:27:57PM +0200, Avi Kivity wrote:
The approach with the export notifier is page based not based on the
mm_struct. We only need a single page count for a page that is exported to
a number of remote instances of linux. The page count is dropped when all
the remote
Christoph, Maybe you can clear one thing up. Was this proposal an
addition to or replacement of Andrea's? I assumed an addition. I am
going to try to restrict my responses to ones appropriate for that
assumption.
The remote instance is like a secondary TLB what you're doing in your
code is
Why don't you stick to mm+va and use get_user_pages and let the VM do
the swapins etc...?
Our concern is also with memory protections for the physical page.
Additionally, we need to support exporting of memory in a VM_PFNMAP
address ranges (specifically, memory mapped using sgi_fetchop,
On Wed, Jan 23, 2008 at 01:51:23PM +0100, Gerd Hoffmann wrote:
Jumping in here, looks like this could develop into a direction useful
for Xen.
Background: Xen has a mechanism called grant tables for page sharing.
Guest #1 can issue a grant for another guest #2, which in turn then
can use
On Wed, Jan 23, 2008 at 03:12:36PM +0100, Gerd Hoffmann wrote:
Hi,
That would render the notifies useless for Xen too. Xen needs to
intercept the actual pte clear and instead of just zapping it use the
hypercall to do the unmap and release the grant.
We are tackling that by having
On Wed, Jan 23, 2008 at 03:35:54PM +0100, Gerd Hoffmann wrote:
Robin Holt wrote:
We have a seg structure which is similar to some structure you probably
have which describes the grant. One of the things hanging off that
seg structure is essentially a page table containing PFNs
On Wed, Jan 23, 2008 at 11:48:43AM -0800, Christoph Lameter wrote:
On Wed, 23 Jan 2008, Andrea Arcangeli wrote:
On Wed, Jan 23, 2008 at 04:52:47AM -0600, Robin Holt wrote:
But 100 callouts holding spinlocks will not work for our implementation
and even if the callouts are made
or early Friday. This has not even been compiled yet. Just
marking it up for now.
Thank you for your attention,
Robin Holt
Index: mmu_notifiers/include/linux/export_notifier.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
this is getting
to the point where we can start testing. It does compile now.
I am traveling tomorrow but should be able to get back to this tomorrow
evening or early Friday.
Thank you for your attention,
Robin Holt
Index: mmu_notifiers/include/linux/export_notifier.h
have never used.
Thanks,
Robin Holt
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01
On Sat, Jan 12, 2008 at 09:51:56PM +0200, Avi Kivity wrote:
Christoph Lameter wrote:
On Thu, 10 Jan 2008, Avi Kivity wrote:
Actually sharing memory is possible even without this patch; one simply
mmap()s a file into the address space of both guests. Or are you
referring to
something
On Thu, Jan 10, 2008 at 03:27:24PM +0200, Avi Kivity wrote:
Robin Holt wrote:
The patch does enable some nifty things; one example you may be familiar
with is using page migration to move a guest from one numa node to
another.
xpmem allows one MPI rank to export his address space
98 matches
Mail list logo
