On Fri, 1 Feb 2008, 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.
Talked to Jack last night and he said its okay.
--
To
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
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
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
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.
On Fri, 1 Feb 2008, 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.
Talked to Jack last night and he said its okay.
--
To
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.
This first portion is fitting for external mmu's
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.
This first portion is fitting for external mmu's
On Sat, 26 Jan 2008, Robin Holt wrote:
> > No you cannot do that because there are still callbacks that come later.
> > The invalidate_all may lead to invalidate_range() doing nothing for this
> > mm. The ops notifier and the freeing of the structure has to wait until
> > release().
>
> Could
On Sat, 26 Jan 2008, Robin Holt wrote:
> But what if the caller is already holding the mmap_sem? Why force the
> acquire into this function? Since we are dealing with a semaphore/mutex,
Then you need to call __register_mmu_notifier.
--
To unsubscribe from this list: send the line "unsubscribe
On Sat, 26 Jan 2008, Robin Holt wrote:
But what if the caller is already holding the mmap_sem? Why force the
acquire into this function? Since we are dealing with a semaphore/mutex,
Then you need to call __register_mmu_notifier.
--
To unsubscribe from this list: send the line unsubscribe
On Sat, 26 Jan 2008, Robin Holt wrote:
No you cannot do that because there are still callbacks that come later.
The invalidate_all may lead to invalidate_range() doing nothing for this
mm. The ops notifier and the freeing of the structure has to wait until
release().
Could you be a
> void mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm)
> {
> - spin_lock(_notifier_list_lock);
> - hlist_add_head(>hlist, >mmu_notifier.head);
> - spin_unlock(_notifier_list_lock);
> + down_write(>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
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
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);
+
Diff so far against V1
- Improve RCU support. (There is now a sychronize_rcu in mmu_release which
is bad.)
- Clean compile for !MMU_NOTIFIER
- Use mmap_sem for serializing additions the mmu_notifier list in the
mm_struct (but still global spinlock for mmu_rmap_notifier. The
registration
On Fri, 25 Jan 2008, Robin Holt wrote:
> Keep in mind that on a 2048p SSI MPI job starting up, we have 2048 ranks
> doing this at the same time 6 times withing their address range. That
> seems like a lock which could get hot fairly quickly. It may be for a
> short period during startup and
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
On Fri, 25 Jan 2008, Robin Holt wrote:
> > > > +void mmu_notifier_release(struct mm_struct *mm)
> > > > +{
> > > > + struct mmu_notifier *mn;
> > > > + struct hlist_node *n;
> > > > +
> > > > + if (unlikely(!hlist_empty(>mmu_notifier.head))) {
> > > > +
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
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 to not use column 81.
Found a couple of more 80 column infractions.
> +#define mmu_notifier(function, mm, args...) \
...
> + if (__mn->ops->function)\
> + __mn->ops->function(__mn, \
> + mm,
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, 25 Jan 2008, Robin Holt wrote:
+void mmu_notifier_release(struct mm_struct *mm)
+{
+ struct mmu_notifier *mn;
+ struct hlist_node *n;
+
+ if (unlikely(!hlist_empty(mm-mmu_notifier.head))) {
+ rcu_read_lock();
+
+#define mmu_notifier(function, mm, args...) \
...
+ if (__mn-ops-function)\
+ __mn-ops-function(__mn, \
+ mm, \
+
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 to not use column 81.
Found a couple of more 80 column infractions. Will
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 Fri, 25 Jan 2008, Robin Holt wrote:
Keep in mind that on a 2048p SSI MPI job starting up, we have 2048 ranks
doing this at the same time 6 times withing their address range. That
seems like a lock which could get hot fairly quickly. It may be for a
short period during startup and
Diff so far against V1
- Improve RCU support. (There is now a sychronize_rcu in mmu_release which
is bad.)
- Clean compile for !MMU_NOTIFIER
- Use mmap_sem for serializing additions the mmu_notifier list in the
mm_struct (but still global spinlock for mmu_rmap_notifier. The
registration
Core code for mmu notifiers.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
---
include/linux/mm_types.h |8 ++
include/linux/mmu_notifier.h | 152 +++
include/linux/page-flags.h |9
Core code for mmu notifiers.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: Andrea Arcangeli [EMAIL PROTECTED]
---
include/linux/mm_types.h |8 ++
include/linux/mmu_notifier.h | 152 +++
include/linux/page-flags.h |9 ++
32 matches
Mail list logo
