On Fri, 29 Jan 2016, Davidlohr Bueso wrote:
> On Wed, 27 Jan 2016, Hugh Dickins wrote:
>
> > > + *
> > > + * The RCU read lock is taken as the inode is finally freed
> > > + * under RCU. If the mapping still matches expectations then
> > > the
> > > + * mapping-
On Wed, 27 Jan 2016, Hugh Dickins wrote:
+*
+* The RCU read lock is taken as the inode is finally freed
+* under RCU. If the mapping still matches expectations then the
+* mapping->host can be safely accessed as being a valid inode.
On Sat, 23 Jan 2016, Davidlohr Bueso wrote:
> From: Mel Gorman
>
> When dealing with key handling for shared futexes, we can drastically reduce
> the usage/need of the page lock. 1) For anonymous pages, the associated futex
> object is the mm_struct which does not require the page lock. 2) For i
On Sat, 23 Jan 2016, Davidlohr Bueso wrote:
> + if (unlikely(!mapping)) {
> + int shmem_swizzled;
> +
> + /*
> + * Page lock is required to identify which special case above
> + * applies. If this is really a shmem page then the page lock
> +
From: Mel Gorman
When dealing with key handling for shared futexes, we can drastically reduce
the usage/need of the page lock. 1) For anonymous pages, the associated futex
object is the mm_struct which does not require the page lock. 2) For inode
based, keys, we can check under RCU read lock if t
5 matches
Mail list logo
