* 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).