On Thu, Jan 24, 2013 at 10:15:35AM -0800, Greg KH wrote:
> On Thu, Jan 24, 2013 at 09:28:51AM -0600, Robin Holt wrote:
> >
> > I missed the email from 12/31 indicating commit 891348c was pulled from
> > the 3.0.y stable tree due to a build breakage.
> >
> > That
I missed the email from 12/31 indicating commit 891348c was pulled from
the 3.0.y stable tree due to a build breakage.
That commit requires the enum defined in traps.h by commit c940826. That,
in turn depends on commit 228bdaa95f which depends upon earlier commits.
How should I proceed?
I missed the email from 12/31 indicating commit 891348c was pulled from
the 3.0.y stable tree due to a build breakage.
That commit requires the enum defined in traps.h by commit c940826. That,
in turn depends on commit 228bdaa95f which depends upon earlier commits.
How should I proceed?
On Thu, Jan 24, 2013 at 10:15:35AM -0800, Greg KH wrote:
On Thu, Jan 24, 2013 at 09:28:51AM -0600, Robin Holt wrote:
I missed the email from 12/31 indicating commit 891348c was pulled from
the 3.0.y stable tree due to a build breakage.
That commit requires the enum defined in traps.h
On Thu, Jan 24, 2013 at 12:00:34PM -0800, Greg KH wrote:
On Thu, Jan 24, 2013 at 12:30:10PM -0600, Robin Holt wrote:
On Thu, Jan 24, 2013 at 10:15:35AM -0800, Greg KH wrote:
On Thu, Jan 24, 2013 at 09:28:51AM -0600, Robin Holt wrote:
I missed the email from 12/31 indicating commit
On Thu, Jan 24, 2013 at 12:50:50PM -0800, Greg KH wrote:
On Thu, Jan 24, 2013 at 02:14:20PM -0600, Robin Holt wrote:
On Thu, Jan 24, 2013 at 12:00:34PM -0800, Greg KH wrote:
On Thu, Jan 24, 2013 at 12:30:10PM -0600, Robin Holt wrote:
On Thu, Jan 24, 2013 at 10:15:35AM -0800, Greg KH
On Wed, Jan 02, 2013 at 01:13:43PM -0600, Nathan Zimmer wrote:
> On 01/02/2013 12:04 PM, H. Peter Anvin wrote:
> >On 01/02/2013 09:21 AM, Nathan Zimmer wrote:
> >>I am getting an early boot problem. It only happens on the larger of the
> >>machines I haven't seen it crop up on machines with more
On Wed, Jan 02, 2013 at 01:13:43PM -0600, Nathan Zimmer wrote:
On 01/02/2013 12:04 PM, H. Peter Anvin wrote:
On 01/02/2013 09:21 AM, Nathan Zimmer wrote:
I am getting an early boot problem. It only happens on the larger of the
machines I haven't seen it crop up on machines with more then 512
callouts for reasons which will not actually lead
to a system to continue on to call die().
To: Andrew Morton
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Linux-kernel
Cc:
Signed-off-by: Robin Holt
---
This is essentially a resend. Originally, I sent it to Thomas and Ingo as
they had originally
callouts for reasons which will not actually lead
to a system to continue on to call die().
To: Andrew Morton a...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@elte.hu
Cc: Linux-kernel linux-kernel@vger.kernel.org
Cc: sta...@kernel.org
Signed-off-by: Robin Holt h
callouts for reasons which will not actually lead
to a system to continue on to call die().
To: Thomas Gleixner
To: Ingo Molnar
Cc: Linux-kernel
Cc:
Signed-off-by: Robin Holt
diff --git a/drivers/misc/sgi-xp/xpc_main.c b/drivers/misc/sgi-xp/xpc_main.c
index 8d082b4..03130cb 100644
--- a/drivers
callouts for reasons which will not actually lead
to a system to continue on to call die().
To: Thomas Gleixner t...@linutronix.de
To: Ingo Molnar mi...@elte.hu
Cc: Linux-kernel linux-kernel@vger.kernel.org
Cc: sta...@kernel.org
Signed-off-by: Robin Holt h...@sgi.com
diff --git a/drivers/misc/sgi-xp
as all the other GRU Message Queue
structures) specifiable as a module load param and has a default
behavior of searching all nodes/cpus for an available resources.
Signed-off-by: Robin Holt
Cc: sta...@vger.kernel.org
---
-v2 - incorporate review comments from Andrew Morton.
drivers/misc/sgi-xp
as all the other GRU Message Queue
structures) specifiable as a module load param and has a default
behavior of searching all nodes/cpus for an available resources.
Signed-off-by: Robin Holt h...@sgi.com
Cc: sta...@vger.kernel.org
---
-v2 - incorporate review comments from Andrew Morton.
drivers
register_netdev() was causing the
> network interface to miss a linkwatch pending event leading to an
> inconsistent state if the link is not up when interface is initialized.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Ilya Shchepetkov
Acked-
the
network interface to miss a linkwatch pending event leading to an
inconsistent state if the link is not up when interface is initialized.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Ilya Shchepetkov shchepet...@ispras.ru
Acked-by: Robin Holt h...@sgi.com
as all the other GRU Message Queue
structures) specifiable as a module load param and has a default
behavior of searching all nodes/cpus for an available resource.
Signed-off-by: Robin Holt
---
drivers/misc/sgi-xp/xpc_uv.c | 66 -
1 files changed, 51
as all the other GRU Message Queue
structures) specifiable as a module load param and has a default
behavior of searching all nodes/cpus for an available resource.
Signed-off-by: Robin Holt h...@sgi.com
---
drivers/misc/sgi-xp/xpc_uv.c | 66 -
1 files changed
> > 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
>
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
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
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 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 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 allo
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
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
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
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
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: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 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 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 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:
>
> > &
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
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:
> > You can't sleep inside rcu_read_lock()!
> >
> > I must say that for a patch that is up to v8 or whatever and is
> > posted twice a week to such a big cc list, it is
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 to be _more_ permissive, and I don't
> >
> > Note that in my patch
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 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
>
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 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 to be _more_ permissive, and I don't
Note that in my patch the
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:00:38AM +0100, Andrea Arcangeli wrote:
On Wed, Feb 20, 2008 at 10:08:49AM +1100, Nick Piggin wrote:
You can't sleep inside rcu_read_lock()!
I must say that for a patch that is up to v8 or whatever and is
posted twice a week to such a big cc list, it is kind of
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
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
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 Thu, Feb 14, 2008 at 09:09:08AM -0600, Steve Wise wrote:
> Note that for T3, this involves suspending _all_ rdma connections that are
> in the same PD as the MR being remapped. This is because the driver
> doesn't know who the application advertised the rkey/stag to. So without
Is there a
On Thu, Feb 14, 2008 at 09:09:08AM -0600, Steve Wise wrote:
Note that for T3, this involves suspending _all_ rdma connections that are
in the same PD as the MR being remapped. This is because the driver
doesn't know who the application advertised the rkey/stag to. So without
Is there a
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 t
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
>
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
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?
Great news! I have taken over Dean's xpmem patch set while he is on
sabbatical. Before he left, he had his patch mostly working on top of
this patch set. We had one deadlock. I have coded for that specific
deadlock and xpmem now passes a simple grant/attach/fault/fork/unmap/map
test.
After
Great news! I have taken over Dean's xpmem patch set while he is on
sabbatical. Before he left, he had his patch mostly working on top of
this patch set. We had one deadlock. I have coded for that specific
deadlock and xpmem now passes a simple grant/attach/fault/fork/unmap/map
test.
After
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 tha
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 getti
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
> > to read-write. Jack and I can not see a reason we would need that
> > callout.
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
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 restri
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
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
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
do_wp_page can reach the _end callout without passing the _begin
callout. This prevents making the _end unles the _begin has also
been made.
Index: mmu_notifiers-cl-v5/mm/memory.c
===
--- mmu_notifiers-cl-v5.orig/mm/memory.c
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
> > > ...
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 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
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
do_wp_page can reach the _end callout without passing the _begin
callout. This prevents making the _end unles the _begin has also
been made.
Index: mmu_notifiers-cl-v5/mm/memory.c
===
--- mmu_notifiers-cl-v5.orig/mm/memory.c
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
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 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
to read-write. Jack and I can not see a reason we would need that
callout. It is causing problems for xpmem
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
> 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(invalidate_range_end, mm, 0);
I think we can get an _end call without the _begin call before it.
Thanks,
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 w
> 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
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 u
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
Christoph,
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.
Thanks,
Robin
Index: mmu_notifiers-cl-v4/include/linux/mm_types.h
===
---
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);
> >
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
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
Christoph,
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.
Thanks,
Robin
Index: mmu_notifiers-cl-v4/include/linux/mm_types.h
===
---
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
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);
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
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(invalidate_range_end, mm, 0);
I think we can get an _end call without the _begin call before it.
Thanks,
Robin
--
501 - 600 of 747 matches
Mail list logo
