lkml.org 
[lkml]   [2019]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC 02/15] slub: Add isolate() and migrate() methods
    On Sat, Mar 09, 2019 at 06:53:22AM +1100, Tobin C. Harding wrote:
    > On Fri, Mar 08, 2019 at 09:22:37AM -0700, Tycho Andersen wrote:
    > > On Fri, Mar 08, 2019 at 04:15:46PM +0000, Christopher Lameter wrote:
    > > > On Fri, 8 Mar 2019, Tycho Andersen wrote:
    > > >
    > > > > On Fri, Mar 08, 2019 at 03:14:13PM +1100, Tobin C. Harding wrote:
    > > > > > diff --git a/mm/slab_common.c b/mm/slab_common.c
    > > > > > index f9d89c1b5977..754acdb292e4 100644
    > > > > > --- a/mm/slab_common.c
    > > > > > +++ b/mm/slab_common.c
    > > > > > @@ -298,6 +298,10 @@ int slab_unmergeable(struct kmem_cache *s)
    > > > > > if (!is_root_cache(s))
    > > > > > return 1;
    > > > > >
    > > > > > + /*
    > > > > > + * s->isolate and s->migrate imply s->ctor so no need to
    > > > > > + * check them explicitly.
    > > > > > + */
    > > > >
    > > > > Shouldn't this implication go the other way, i.e.
    > > > > s->ctor => s->isolate & s->migrate
    > > >
    > > > A cache can have a constructor but the object may not be movable (I.e.
    > > > currently dentries and inodes).
    > >
    > > Yep, thanks. Somehow I got confused by the comment.
    >
    > I removed code here from the original RFC-v2, if this comment is
    > confusing perhaps we are better off without it.

    I'd say leave it, unless others have objections. I got lost in the
    "no need" and return true for unmergable too-many-nots goop, but it's
    definitely worth noting that one implies the other. An alternative
    might be to move it to a comment on the struct member instead.

    Tycho

    \
     
     \ /
      Last update: 2019-03-08 21:09    [W:3.073 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site