lkml.org 
[lkml]   [2014]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] slub: Do not assert not having lock in removing freed partial
On Wed, 5 Feb 2014 16:46:43 -0800 (PST)
David Rientjes <rientjes@google.com> wrote:


> > +/*
> > + * The difference between remove_partial and remove_freed_partial
> > + * is that remove_freed_partial happens only on a a freed slab
>
> Duplicate "a" there.

oops.

>
> > + * that should not have anyone accessing it, and thus does not
> > + * require the n->list_lock.
> > + */
> > +static inline void remove_freed_partial(struct kmem_cache_node *n,
> > + struct page *page)
> > +{
> > + __remove_partial(n, page);
> > }
> >
> > /*
> > @@ -3195,7 +3212,7 @@ static void free_partial(struct kmem_cac
> >
> > list_for_each_entry_safe(page, h, &n->partial, lru) {
> > if (!page->inuse) {
> > - remove_partial(n, page);
> > + remove_freed_partial(n, page);
> > discard_slab(s, page);
> > } else {
> > list_slab_objects(s, page,
>
> We'll want to do something similiar for the add_partial() called from
> early_kmem_cache_node_alloc(), right? It had the added n->list_lock for
> the same reason and is done during early init where nobody else can be
> referencing a kmem_cache_node.
>
> It would probably be better to define these in terms of "partial slabs
> that cannot have anyone else accessing it" rather than "freed slabs".

Perhaps then we just use the __remove_partial() and __add_partial()
that does not do the checks. That's common practice to use a "__" to
denote that it's special and usually doesn't require locking.

-- Steve


\
 
 \ /
  Last update: 2014-02-06 02:21    [W:0.054 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site