It seems that we've come up with two reasonable cases where it makes
sense to use these notifiers for InfiniBand/RDMA:
First, the ability to safely to DMA to/from userspace memory with the
memory regions mlock()ed but the pages not pinned. In this case the
notifiers here would seem to suit us
It seems that we've come up with two reasonable cases where it makes
sense to use these notifiers for InfiniBand/RDMA:
First, the ability to safely to DMA to/from userspace memory with the
memory regions mlock()ed but the pages not pinned. In this case the
notifiers here would seem to suit us
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 Fri, 15 Feb 2008 19:37:19 PST, Andrew Morton wrote:
> Which other potential clients have been identified and how important it it
> to those?
The powerpc ehea utilizes its own mmu. Not sure about the importance
to the driver. (But will investigate :)
++doug
--
To unsubscribe from this
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 seems the IB folks think allowing RDMA over virtual memory is not
On Sat, 16 Feb 2008, Andrew Morton wrote:
> "looks good" maybe. But it's in the details where I fear this will come
> unstuck. The likelihood that some callbacks really will want to be able to
> block in places where this interface doesn't permit that - either to wait
> for IO to complete or to
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.
>
> How important is this feature to KVM?
Andrea can answer this.
> To xpmem?
Without this feature we are stuck with page pinning by increasing
On Sat, 16 Feb 2008 11:41:35 +0100 Brice Goglin <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > What is the status of getting infiniband to use this facility?
> >
> > How important is this feature to KVM?
> >
> > To xpmem?
> >
> > Which other potential clients have been identified and how
Andrew Morton wrote:
> What is the status of getting infiniband to use this facility?
>
> How important is this feature to KVM?
>
> To xpmem?
>
> Which other potential clients have been identified and how important it it
> to those?
>
As I said when Andrea posted the first patch series, I used
Andrew Morton wrote:
Very. kvm pins pages that are referenced by the guest;
hm. Why does it do that?
It was deemed best not to allow the guest to write to a page that has
been swapped out and assigned to an unrelated host process.
One way to view the kvm shadow page tables
On Sat, 16 Feb 2008 10:45:50 +0200 Avi Kivity <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > How important is this feature to KVM?
> >
>
> Very. kvm pins pages that are referenced by the guest;
hm. Why does it do that?
> a 64-bit guest
> will easily pin its entire memory with the
Andrew Morton wrote:
How important is this feature to KVM?
Very. kvm pins pages that are referenced by the guest; a 64-bit guest
will easily pin its entire memory with the kernel map. So this is
critical for guest swapping to actually work.
Other nice features like page migration are
Andrew Morton wrote:
How important is this feature to KVM?
Very. kvm pins pages that are referenced by the guest; a 64-bit guest
will easily pin its entire memory with the kernel map. So this is
critical for guest swapping to actually work.
Other nice features like page migration are
On Sat, 16 Feb 2008 10:45:50 +0200 Avi Kivity [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
How important is this feature to KVM?
Very. kvm pins pages that are referenced by the guest;
hm. Why does it do that?
a 64-bit guest
will easily pin its entire memory with the kernel map.
Andrew Morton wrote:
Very. kvm pins pages that are referenced by the guest;
hm. Why does it do that?
It was deemed best not to allow the guest to write to a page that has
been swapped out and assigned to an unrelated host process.
One way to view the kvm shadow page tables
Andrew Morton wrote:
What is the status of getting infiniband to use this facility?
How important is this feature to KVM?
To xpmem?
Which other potential clients have been identified and how important it it
to those?
As I said when Andrea posted the first patch series, I used
On Sat, 16 Feb 2008 11:41:35 +0100 Brice Goglin [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
What is the status of getting infiniband to use this facility?
How important is this feature to KVM?
To xpmem?
Which other potential clients have been identified and how important it it
On Sat, 16 Feb 2008, Andrew Morton wrote:
looks good maybe. But it's in the details where I fear this will come
unstuck. The likelihood that some callbacks really will want to be able to
block in places where this interface doesn't permit that - either to wait
for IO to complete or to wait
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.
How important is this feature to KVM?
Andrea can answer this.
To xpmem?
Without this feature we are stuck with page pinning by increasing
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 seems the IB folks think allowing RDMA over virtual memory is not
On Fri, 15 Feb 2008 19:37:19 PST, Andrew Morton wrote:
Which other potential clients have been identified and how important it it
to those?
The powerpc ehea utilizes its own mmu. Not sure about the importance
to the driver. (But will investigate :)
++doug
--
To unsubscribe from this list:
On Thu, 14 Feb 2008 22:49:00 -0800 Christoph Lameter <[EMAIL PROTECTED]> wrote:
> MMU notifiers are used for hardware and software that establishes
> external references to pages managed by the Linux kernel. These are
> page table entriews or tlb entries or something else that allows
> hardware
On Thu, 14 Feb 2008 22:49:00 -0800 Christoph Lameter [EMAIL PROTECTED] wrote:
MMU notifiers are used for hardware and software that establishes
external references to pages managed by the Linux kernel. These are
page table entriews or tlb entries or something else that allows
hardware (such
MMU notifiers are used for hardware and software that establishes
external references to pages managed by the Linux kernel. These are
page table entriews or tlb entries or something else that allows
hardware (such as DMA engines, scatter gather devices, networking,
sharing of address spaces across
MMU notifiers are used for hardware and software that establishes
external references to pages managed by the Linux kernel. These are
page table entriews or tlb entries or something else that allows
hardware (such as DMA engines, scatter gather devices, networking,
sharing of address spaces across
MMU notifiers are used for hardware and software that establishes
external references to pages managed by the Linux kernel. These are
page table entriews or tlb entries or something else that allows
hardware (such as DMA engines, scatter gather devices, networking,
sharing of address spaces across
MMU notifiers are used for hardware and software that establishes
external references to pages managed by the Linux kernel. These are
page table entriews or tlb entries or something else that allows
hardware (such as DMA engines, scatter gather devices, networking,
sharing of address spaces across
On Tue, 5 Feb 2008, Andy Whitcroft wrote:
> > + if (unlikely(!hlist_empty(>mmu_notifier.head))) {
> > + rcu_read_lock();
> > + hlist_for_each_entry_safe_rcu(mn, n, t,
> > + >mmu_notifier.head, hlist) {
> > + if
On Tue, 2008-02-05 at 18:05 +, Andy Whitcroft wrote:
> > + if (unlikely(!hlist_empty(>mmu_notifier.head))) {
> > + rcu_read_lock();
> > + hlist_for_each_entry_safe_rcu(mn, n, t,
> > + >mmu_notifier.head, hlist) {
> > +
On Mon, Jan 28, 2008 at 12:28:41PM -0800, Christoph Lameter wrote:
> Core code for mmu notifiers.
>
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
> Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
>
> ---
> include/linux/list.h | 14 ++
> include/linux/mm_types.h |
On Mon, Jan 28, 2008 at 12:28:41PM -0800, Christoph Lameter wrote:
Core code for mmu notifiers.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: Andrea Arcangeli [EMAIL PROTECTED]
---
include/linux/list.h | 14 ++
include/linux/mm_types.h |6 +
On Tue, 2008-02-05 at 18:05 +, Andy Whitcroft wrote:
+ if (unlikely(!hlist_empty(mm-mmu_notifier.head))) {
+ rcu_read_lock();
+ hlist_for_each_entry_safe_rcu(mn, n, t,
+ mm-mmu_notifier.head, hlist) {
+ if
On Tue, 5 Feb 2008, Andy Whitcroft wrote:
+ if (unlikely(!hlist_empty(mm-mmu_notifier.head))) {
+ rcu_read_lock();
+ hlist_for_each_entry_safe_rcu(mn, n, t,
+ mm-mmu_notifier.head, hlist) {
+ if (mn-ops-release)
On Thu, 31 Jan 2008, Andrea Arcangeli wrote:
> > H.. exit_mmap is only called when the last reference is removed
> > against the mm right? So no tasks are running anymore. No pages are left.
> > Do we need to serialize at all for mmu_notifier_release?
>
> KVM sure doesn't need any locking
On Wed, Jan 30, 2008 at 03:55:37PM -0800, Christoph Lameter wrote:
> On Thu, 31 Jan 2008, Andrea Arcangeli wrote:
>
> > > I think Andrea's original concept of the lock in the mmu_notifier_head
> > > structure was the best. I agree with him that it should be a spinlock
> > > instead of the
On Thu, 31 Jan 2008, Andrea Arcangeli wrote:
> > I think Andrea's original concept of the lock in the mmu_notifier_head
> > structure was the best. I agree with him that it should be a spinlock
> > instead of the rw_lock.
>
> BTW, I don't see the scalability concern with huge number of tasks:
>
On Wed, Jan 30, 2008 at 04:20:35PM -0600, Robin Holt wrote:
> On Wed, Jan 30, 2008 at 11:19:28AM -0800, Christoph Lameter wrote:
> > On Wed, 30 Jan 2008, Jack Steiner wrote:
> >
> > > Moving to a different lock solves the problem.
> >
> > Well it gets us back to the issue why we removed the
On Wed, Jan 30, 2008 at 11:19:28AM -0800, Christoph Lameter wrote:
> On Wed, 30 Jan 2008, Jack Steiner wrote:
>
> > Moving to a different lock solves the problem.
>
> Well it gets us back to the issue why we removed the lock. As Robin said
> before: If its global then we can have a huge number
How about just taking the mmap_sem writelock in release? We have only a
single caller of mmu_notifier_release() in mm/mmap.c and we know that we
are not holding mmap_sem at that point. So just acquire it when needed?
Index: linux-2.6/mm/mmu_notifier.c
On Wed, 30 Jan 2008, Jack Steiner wrote:
> Moving to a different lock solves the problem.
Well it gets us back to the issue why we removed the lock. As Robin said
before: If its global then we can have a huge number of tasks contending
for the lock on startup of a process with a large number
Ok. So I added the following patch:
---
include/linux/mmu_notifier.h |1 +
mm/mmu_notifier.c| 12
2 files changed, 13 insertions(+)
Index: linux-2.6/include/linux/mmu_notifier.h
===
---
On Wed, 30 Jan 2008, Robin Holt wrote:
> Index: git-linus/mm/mmu_notifier.c
> ===
> --- git-linus.orig/mm/mmu_notifier.c 2008-01-30 11:43:45.0 -0600
> +++ git-linus/mm/mmu_notifier.c 2008-01-30 11:56:08.0 -0600
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
On Wed, 2008-01-30 at 16:37 +0100, Andrea Arcangeli wrote:
> On Tue, Jan 29, 2008 at 06:29:10PM -0800, Christoph Lameter wrote:
> > +void mmu_notifier_release(struct mm_struct *mm)
> > +{
> > + struct mmu_notifier *mn;
> > + struct hlist_node *n, *t;
> > +
> > + if
On Wed, Jan 30, 2008 at 09:53:06AM -0600, Jack Steiner wrote:
> That will also resolve the problem we discussed yesterday.
> I want to unregister my mmu_notifier when a GRU segment is
> unmapped. This would not necessarily be at task termination.
My proof that there is something wrong in the smp
On Wed, Jan 30, 2008 at 04:37:49PM +0100, Andrea Arcangeli wrote:
> On Tue, Jan 29, 2008 at 06:29:10PM -0800, Christoph Lameter wrote:
> > +void mmu_notifier_release(struct mm_struct *mm)
> > +{
> > + struct mmu_notifier *mn;
> > + struct hlist_node *n, *t;
> > +
> > + if
On Tue, Jan 29, 2008 at 06:29:10PM -0800, Christoph Lameter wrote:
> +void mmu_notifier_release(struct mm_struct *mm)
> +{
> + struct mmu_notifier *mn;
> + struct hlist_node *n, *t;
> +
> + if (unlikely(!hlist_empty(>mmu_notifier.head))) {
> + rcu_read_lock();
> +
On Wed, Jan 30, 2008 at 04:37:49PM +0100, Andrea Arcangeli wrote:
On Tue, Jan 29, 2008 at 06:29:10PM -0800, Christoph Lameter wrote:
+void mmu_notifier_release(struct mm_struct *mm)
+{
+ struct mmu_notifier *mn;
+ struct hlist_node *n, *t;
+
+ if
On Tue, Jan 29, 2008 at 06:29:10PM -0800, Christoph Lameter wrote:
+void mmu_notifier_release(struct mm_struct *mm)
+{
+ struct mmu_notifier *mn;
+ struct hlist_node *n, *t;
+
+ if (unlikely(!hlist_empty(mm-mmu_notifier.head))) {
+ rcu_read_lock();
+
On Wed, Jan 30, 2008 at 09:53:06AM -0600, Jack Steiner wrote:
That will also resolve the problem we discussed yesterday.
I want to unregister my mmu_notifier when a GRU segment is
unmapped. This would not necessarily be at task termination.
My proof that there is something wrong in the smp
On Wed, 2008-01-30 at 16:37 +0100, Andrea Arcangeli wrote:
On Tue, Jan 29, 2008 at 06:29:10PM -0800, Christoph Lameter wrote:
+void mmu_notifier_release(struct mm_struct *mm)
+{
+ struct mmu_notifier *mn;
+ struct hlist_node *n, *t;
+
+ if
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
On Wed, 30 Jan 2008, Robin Holt wrote:
Index: git-linus/mm/mmu_notifier.c
===
--- git-linus.orig/mm/mmu_notifier.c 2008-01-30 11:43:45.0 -0600
+++ git-linus/mm/mmu_notifier.c 2008-01-30 11:56:08.0 -0600
@@
On Wed, 30 Jan 2008, Jack Steiner wrote:
Moving to a different lock solves the problem.
Well it gets us back to the issue why we removed the lock. As Robin said
before: If its global then we can have a huge number of tasks contending
for the lock on startup of a process with a large number of
How about just taking the mmap_sem writelock in release? We have only a
single caller of mmu_notifier_release() in mm/mmap.c and we know that we
are not holding mmap_sem at that point. So just acquire it when needed?
Index: linux-2.6/mm/mmu_notifier.c
Ok. So I added the following patch:
---
include/linux/mmu_notifier.h |1 +
mm/mmu_notifier.c| 12
2 files changed, 13 insertions(+)
Index: linux-2.6/include/linux/mmu_notifier.h
===
---
On Wed, Jan 30, 2008 at 11:19:28AM -0800, Christoph Lameter wrote:
On Wed, 30 Jan 2008, Jack Steiner wrote:
Moving to a different lock solves the problem.
Well it gets us back to the issue why we removed the lock. As Robin said
before: If its global then we can have a huge number of
On Thu, 31 Jan 2008, Andrea Arcangeli wrote:
I think Andrea's original concept of the lock in the mmu_notifier_head
structure was the best. I agree with him that it should be a spinlock
instead of the rw_lock.
BTW, I don't see the scalability concern with huge number of tasks:
the lock
On Wed, Jan 30, 2008 at 04:20:35PM -0600, Robin Holt wrote:
On Wed, Jan 30, 2008 at 11:19:28AM -0800, Christoph Lameter wrote:
On Wed, 30 Jan 2008, Jack Steiner wrote:
Moving to a different lock solves the problem.
Well it gets us back to the issue why we removed the lock. As Robin
On Wed, Jan 30, 2008 at 03:55:37PM -0800, Christoph Lameter wrote:
On Thu, 31 Jan 2008, Andrea Arcangeli wrote:
I think Andrea's original concept of the lock in the mmu_notifier_head
structure was the best. I agree with him that it should be a spinlock
instead of the rw_lock.
On Thu, 31 Jan 2008, Andrea Arcangeli wrote:
H.. exit_mmap is only called when the last reference is removed
against the mm right? So no tasks are running anymore. No pages are left.
Do we need to serialize at all for mmu_notifier_release?
KVM sure doesn't need any locking there.
Core code for mmu notifiers.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
---
include/linux/list.h | 14 ++
include/linux/mm_types.h |6 +
include/linux/mmu_notifier.h | 210
Christoph Lameter wrote:
On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
+ struct mmu_notifier_head mmu_notifier; /* MMU notifier list */
};
Not sure why you prefer to waste ram when MMU_NOTIFIER=n, this is a
regression (a minor one though).
Andrew does not like #ifdefs
On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
> > + struct mmu_notifier_head mmu_notifier; /* MMU notifier list */
> > };
>
> Not sure why you prefer to waste ram when MMU_NOTIFIER=n, this is a
> regression (a minor one though).
Andrew does not like #ifdefs and it makes it possible to verify
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,
> + >mmu_notifier.head, hlist) {
> +
On Tue, Jan 29, 2008 at 02:59:14PM +0100, Andrea Arcangeli wrote:
> The down_write is garbage. The caller should put it around
> mmu_notifier_register if something. The same way the caller should
> call synchronize_rcu after mmu_notifier_register if it needs
> synchronous behavior from the
On Mon, Jan 28, 2008 at 12:28:41PM -0800, Christoph Lameter wrote:
> +struct mmu_notifier_head {
> + struct hlist_head head;
> +};
> +
> struct mm_struct {
> struct vm_area_struct * mmap; /* list of VMAs */
> struct rb_root mm_rb;
> @@ -219,6 +223,8 @@ struct mm_struct {
On Mon, Jan 28, 2008 at 12:28:41PM -0800, Christoph Lameter wrote:
+struct mmu_notifier_head {
+ struct hlist_head head;
+};
+
struct mm_struct {
struct vm_area_struct * mmap; /* list of VMAs */
struct rb_root mm_rb;
@@ -219,6 +223,8 @@ struct mm_struct {
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) {
+
On Tue, Jan 29, 2008 at 02:59:14PM +0100, Andrea Arcangeli wrote:
The down_write is garbage. The caller should put it around
mmu_notifier_register if something. The same way the caller should
call synchronize_rcu after mmu_notifier_register if it needs
synchronous behavior from the notifiers.
Christoph Lameter wrote:
On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
+ struct mmu_notifier_head mmu_notifier; /* MMU notifier list */
};
Not sure why you prefer to waste ram when MMU_NOTIFIER=n, this is a
regression (a minor one though).
Andrew does not like #ifdefs
On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
+ struct mmu_notifier_head mmu_notifier; /* MMU notifier list */
};
Not sure why you prefer to waste ram when MMU_NOTIFIER=n, this is a
regression (a minor one though).
Andrew does not like #ifdefs and it makes it possible to verify calling
Core code for mmu notifiers.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: Andrea Arcangeli [EMAIL PROTECTED]
---
include/linux/list.h | 14 ++
include/linux/mm_types.h |6 +
include/linux/mmu_notifier.h | 210 +++
On Mon, 28 Jan 2008, Robin Holt wrote:
> USE_AFTER_FREE!!! I made this same comment as well as other relavent
> comments last week.
Must have slipped somehow. Patch needs to be applied after the rcu fix.
Please repeat the other relevant comments if they are still relevant I
thought I had
> +void mmu_notifier_release(struct mm_struct *mm)
...
> + hlist_for_each_entry_safe_rcu(mn, n, t,
> + >mmu_notifier.head, hlist) {
> + if (mn->ops->release)
> + mn->ops->release(mn, mm);
> +
mmu core: Need to use hlist_del
Wrong type of list del in mmu_notifier_release()
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/mmu_notifier.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/mm/mmu_notifier.c
Core code for mmu notifiers.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
---
include/linux/list.h | 14 ++
include/linux/mm_types.h |6 +
include/linux/mmu_notifier.h | 210
Core code for mmu notifiers.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: Andrea Arcangeli [EMAIL PROTECTED]
---
include/linux/list.h | 14 ++
include/linux/mm_types.h |6 +
include/linux/mmu_notifier.h | 210 +++
mmu core: Need to use hlist_del
Wrong type of list del in mmu_notifier_release()
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
mm/mmu_notifier.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/mm/mmu_notifier.c
+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);
+
On Mon, 28 Jan 2008, Robin Holt wrote:
USE_AFTER_FREE!!! I made this same comment as well as other relavent
comments last week.
Must have slipped somehow. Patch needs to be applied after the rcu fix.
Please repeat the other relevant comments if they are still relevant I
thought I had
82 matches
Mail list logo
