linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* commit "slub: Acquire_slab() avoid loop" wrongly causes rest of partial slabs to be skipped?
@ 2020-12-23 12:52 Jann Horn
  2020-12-24  2:23 ` Joonsoo Kim
  0 siblings, 1 reply; 2+ messages in thread
From: Jann Horn @ 2020-12-23 12:52 UTC (permalink / raw)
  To: Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim,
	Andrew Morton
  Cc: Linux-MM

The commit message of commit 7ced371971966 ("slub: Acquire_slab()
avoid loop") claims:

> Avoid the loop in acquire slab and simply fail if there is a conflict.
>
> This will cause the next page on the list to be considered.

However, get_partial_node() looks like this:

static void *get_partial_node(struct kmem_cache *s, struct kmem_cache_node *n,
        struct kmem_cache_cpu *c, gfp_t flags)
{
  struct page *page, *page2;
  void *object = NULL;
  unsigned int available = 0;
  int objects;
[...]
  spin_lock(&n->list_lock);
  list_for_each_entry_safe(page, page2, &n->partial, slab_list) {
    void *t;
[...]
    t = acquire_slab(s, n, page, object == NULL, &objects);
    if (!t)
      break;
[...]
  }
  spin_unlock(&n->list_lock);
  return object;
}

So actually, if the cmpxchg() fails, we'll entirely bail out of
get_partial_node() and might, if the system isn't NUMA, fall back to
allocating more memory with new_slab()? That seems to me like it might
cause fragmented slabs to slowly use more memory than they should over
time.

Should the loop in get_partial_node() be using "continue" instead of
"break" in that case, so that the rest of the partial list will be
considered as the commit message claims?


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: commit "slub: Acquire_slab() avoid loop" wrongly causes rest of partial slabs to be skipped?
  2020-12-23 12:52 commit "slub: Acquire_slab() avoid loop" wrongly causes rest of partial slabs to be skipped? Jann Horn
@ 2020-12-24  2:23 ` Joonsoo Kim
  0 siblings, 0 replies; 2+ messages in thread
From: Joonsoo Kim @ 2020-12-24  2:23 UTC (permalink / raw)
  To: Jann Horn
  Cc: Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim,
	Andrew Morton, Linux-MM

Hello, Jann.

2020년 12월 23일 (수) 오후 9:52, Jann Horn <jannh@google.com>님이 작성:
>
> The commit message of commit 7ced371971966 ("slub: Acquire_slab()
> avoid loop") claims:
>
> > Avoid the loop in acquire slab and simply fail if there is a conflict.
> >
> > This will cause the next page on the list to be considered.
>
> However, get_partial_node() looks like this:
>
> static void *get_partial_node(struct kmem_cache *s, struct kmem_cache_node *n,
>         struct kmem_cache_cpu *c, gfp_t flags)
> {
>   struct page *page, *page2;
>   void *object = NULL;
>   unsigned int available = 0;
>   int objects;
> [...]
>   spin_lock(&n->list_lock);
>   list_for_each_entry_safe(page, page2, &n->partial, slab_list) {
>     void *t;
> [...]
>     t = acquire_slab(s, n, page, object == NULL, &objects);
>     if (!t)
>       break;
> [...]
>   }
>   spin_unlock(&n->list_lock);
>   return object;
> }
>
> So actually, if the cmpxchg() fails, we'll entirely bail out of
> get_partial_node() and might, if the system isn't NUMA, fall back to
> allocating more memory with new_slab()? That seems to me like it might
> cause fragmented slabs to slowly use more memory than they should over
> time.

Nice catch! I think you are right.

> Should the loop in get_partial_node() be using "continue" instead of
> "break" in that case, so that the rest of the partial list will be
> considered as the commit message claims?

Please send the patch.

Thanks.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-12-24  2:24 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-23 12:52 commit "slub: Acquire_slab() avoid loop" wrongly causes rest of partial slabs to be skipped? Jann Horn
2020-12-24  2:23 ` Joonsoo Kim

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).