Re: [patch 1/3] mmu_notifier: Core code

2008-02-04 Thread Christoph Lameter
On Sun, 3 Feb 2008, Andrea Arcangeli wrote: > On Thu, Jan 31, 2008 at 07:58:40PM -0800, Christoph Lameter wrote: > > Ok. Andrea wanted the same because then he can void the begin callouts. > > Exactly. I hope the page-pin will avoid me having to serialize the KVM > page fault against the start/en

Re: [patch 1/3] mmu_notifier: Core code

2008-02-02 Thread Andrea Arcangeli
On Thu, Jan 31, 2008 at 07:58:40PM -0800, Christoph Lameter wrote: > Ok. Andrea wanted the same because then he can void the begin callouts. Exactly. I hope the page-pin will avoid me having to serialize the KVM page fault against the start/end critical section. BTW, I wonder if the start/end cri

Re: [patch 1/3] mmu_notifier: Core code

2008-01-31 Thread Robin Holt
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 her

Re: [patch 1/3] mmu_notifier: Core code

2008-01-31 Thread Christoph Lameter
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. Without it, > the first invalidate_range would have to block fa

Re: [patch 1/3] mmu_notifier: Core code

2008-01-31 Thread Robin Holt
> 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

Re: [patch 1/3] mmu_notifier: Core code

2008-01-31 Thread Christoph Lameter
On Thu, 31 Jan 2008, Jack Steiner wrote: > I currently unlink the mmu_notifier when the last GRU mapping is closed. For > example, if a user does a: > > gru_create_context(); > ... > gru_destroy_context(); > > the mmu_notifier is unlinked and all task tables allocated > b

Re: [patch 1/3] mmu_notifier: Core code

2008-01-31 Thread Christoph Lameter
On Thu, 31 Jan 2008, Robin Holt wrote: > Both xpmem and GRU have means of removing their context seperate from > process termination. XPMEMs is by closing the fd, I believe GRU is > the same. In the case of XPMEM, we are able to acquire the mmap_sem. > For GRU, I don't think it is possible, but

Re: [patch 1/3] mmu_notifier: Core code

2008-01-31 Thread Jack Steiner
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

Re: [patch 1/3] mmu_notifier: Core code

2008-01-31 Thread Robin Holt
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

Re: [patch 1/3] mmu_notifier: Core code

2008-01-31 Thread Christoph Lameter
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 be needed. ->release removes the mmu_notifier right now. -- To unsubscribe fr

Re: [patch 1/3] mmu_notifier: Core code

2008-01-31 Thread Christoph Lameter
On Thu, 31 Jan 2008, Jack Steiner wrote: > Christoph, is it time to post a new series of patches? I've got > as many fixup patches as I have patches in the original posting. Maybe wait another day? This is getting a bit too frequent and so far we have only minor changes. -- To unsubscribe from

Re: [patch 1/3] mmu_notifier: Core code

2008-01-31 Thread Jack Steiner
On Thu, Jan 31, 2008 at 08:24:44PM -0600, Robin Holt wrote: > 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 */ > >

Re: [patch 1/3] mmu_notifier: Core code

2008-01-31 Thread Robin Holt
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 === --- mmu_no

Re: [patch 1/3] mmu_notifier: Core code

2008-01-31 Thread Robin Holt
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

Re: [patch 1/3] mmu_notifier: Core code

2008-01-31 Thread Jack Steiner
> @@ -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); > The name of the "invalidate_all" callout is not very descr

[patch 1/3] mmu_notifier: Core code

2008-01-30 Thread Christoph Lameter
Notifier functions for hardware and software that establishes external references to pages of a Linux system. The notifier calls ensure that external mappings are removed when the Linux VM removes memory ranges or individual pages from a process. These fall into two classes: 1. mmu_notifier