Re: [RT LATENCY] 249 microsecond latency caused by slub's unfreeze_partials() code.

[Joonsoo Kim <iamjoonsoo.kim@lge.com>]

On Wed, Apr 10, 2013 at 09:31:10AM +0300, Pekka Enberg wrote:
> On Mon, Apr 8, 2013 at 3:32 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >> > Index: linux/mm/slub.c
> >> > ===================================================================
> >> > --- linux.orig/mm/slub.c    2013-03-28 12:14:26.958358688 -0500
> >> > +++ linux/mm/slub.c 2013-04-01 10:23:24.677584499 -0500
> >> > @@ -1498,6 +1498,7 @@ static inline void *acquire_slab(struct
> >> >     void *freelist;
> >> >     unsigned long counters;
> >> >     struct page new;
> >> > +   unsigned long objects;
> >> >
> >> >     /*
> >> >      * Zap the freelist and set the frozen bit.
> >> > @@ -1507,6 +1508,7 @@ static inline void *acquire_slab(struct
> >> >     freelist = page->freelist;
> >> >     counters = page->counters;
> >> >     new.counters = counters;
> >> > +   objects = page->inuse;
> >> >     if (mode) {
> >> >             new.inuse = page->objects;
> >> >             new.freelist = NULL;
> >> > @@ -1524,6 +1526,7 @@ static inline void *acquire_slab(struct
> >> >             return NULL;
> >> >
> >> >     remove_partial(n, page);
> >> > +   page->lru.next = (void *)objects;
> >> >     WARN_ON(!freelist);
> >> >     return freelist;
> >> >  }
> >>
> >> Good. I like your method which use lru.next in order to hand over
> >> number of objects.
> >
> > I hate it ;-)
> >
> > It just seems to be something that's not very robust and can cause hours
> > of debugging in the future. I mean, there's not even a comment
> > explaining what is happening. The lru is a union with other slub
> > partials structs that is not very obvious. If something is out of order,
> > it can easily break, and there's nothing here that points to why.
> >
> > Just pass the damn objects pointer by reference and use that. It's easy
> > to understand, read and is robust.
> 
> Christoph, Joonsoo, comments?

Steven's comment is reasonable to me.

If there is no objection from Christoph,
let's drop a patch in which I implement Christoph's idea.

Thanks.

> 
>                                 Pekka
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/