Re: [PATCH 1/6] mm: make mm->pinned_vm an atomic64 counter

2019-01-28 Thread Andrew Morton
On Wed, 23 Jan 2019 11:33:53 -0700 Jason Gunthorpe wrote: > On Mon, Jan 21, 2019 at 09:42:15AM -0800, Davidlohr Bueso wrote: > > Taking a sleeping lock to _only_ increment a variable is quite the > > overkill, and pretty much all users do this. Furthermore, some drivers > > (ie: infiniband and sc

Re: [PATCH 1/6] mm: make mm->pinned_vm an atomic64 counter

2019-01-23 Thread Jason Gunthorpe
On Mon, Jan 21, 2019 at 09:42:15AM -0800, Davidlohr Bueso wrote: > Taking a sleeping lock to _only_ increment a variable is quite the > overkill, and pretty much all users do this. Furthermore, some drivers > (ie: infiniband and scif) that need pinned semantics can go to quite > some trouble to act

Re: [PATCH 1/6] mm: make mm->pinned_vm an atomic64 counter

2019-01-22 Thread Daniel Jordan
On Mon, Jan 21, 2019 at 09:42:15AM -0800, Davidlohr Bueso wrote: > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > index 6976e17dba68..640ae8a47c73 100644 > --- a/fs/proc/task_mmu.c > +++ b/fs/proc/task_mmu.c > @@ -59,7 +59,7 @@ void task_mem(struct seq_file *m, struct mm_struct *mm) >

Re: [PATCH 1/6] mm: make mm->pinned_vm an atomic64 counter

2019-01-22 Thread Jan Kara
On Mon 21-01-19 09:42:15, Davidlohr Bueso wrote: > Taking a sleeping lock to _only_ increment a variable is quite the > overkill, and pretty much all users do this. Furthermore, some drivers > (ie: infiniband and scif) that need pinned semantics can go to quite > some trouble to actually delay via

Re: [PATCH 1/6] mm: make mm->pinned_vm an atomic64 counter

2019-01-21 Thread Christopher Lameter
On Mon, 21 Jan 2019, Davidlohr Bueso wrote > Taking a sleeping lock to _only_ increment a variable is quite the > overkill, and pretty much all users do this. Furthermore, some drivers > (ie: infiniband and scif) that need pinned semantics can go to quite > some trouble to actually delay via workqu