All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: chengming.zhou@linux.dev, cl@linux.com, penberg@kernel.org
Cc: rientjes@google.com, iamjoonsoo.kim@lge.com,
	akpm@linux-foundation.org, roman.gushchin@linux.dev,
	42.hyeyoo@gmail.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	Chengming Zhou <zhouchengming@bytedance.com>
Subject: Re: [RFC PATCH v3 6/7] slub: Delay freezing of partial slabs
Date: Tue, 31 Oct 2023 10:50:17 +0100	[thread overview]
Message-ID: <6257318a-3d39-ccdf-a85f-dc1008a8f425@suse.cz> (raw)
In-Reply-To: <20231024093345.3676493-7-chengming.zhou@linux.dev>

On 10/24/23 11:33, chengming.zhou@linux.dev wrote:
> From: Chengming Zhou <zhouchengming@bytedance.com>
> 
> Now we will freeze slabs when moving them out of node partial list to
> cpu partial list, this method needs two cmpxchg_double operations:
> 
> 1. freeze slab (acquire_slab()) under the node list_lock
> 2. get_freelist() when pick used in ___slab_alloc()
> 
> Actually we don't need to freeze when moving slabs out of node partial
> list, we can delay freezing to when use slab freelist in ___slab_alloc(),
> so we can save one cmpxchg_double().
> 
> And there are other good points:
>  - The moving of slabs between node partial list and cpu partial list
>    becomes simpler, since we don't need to freeze or unfreeze at all.
> 
>  - The node list_lock contention would be less, since we don't need to
>    freeze any slab under the node list_lock.
> 
> We can achieve this because there is no concurrent path would manipulate
> the partial slab list except the __slab_free() path, which is serialized
> now.

"which is now serialized by slab_test_node_partial() under the list_lock." ?

> Since the slab returned by get_partial() interfaces is not frozen anymore
> and no freelist in the partial_context, so we need to use the introduced

		 ^ is returned in

> freeze_slab() to freeze it and get its freelist.
> 
> Similarly, the slabs on the CPU partial list are not frozen anymore,
> we need to freeze_slab() on it before use.

We can now delete acquire_slab() as it became unused.

> Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com>

With the fixup for CONFIG_SLUB_CPU_PARTIAL you mentioned,
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>

Also agreed with followup patch to rename unfreeze_partials().
Thanks!


  parent reply	other threads:[~2023-10-31  9:50 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-24  9:33 [RFC PATCH v3 0/7] slub: Delay freezing of CPU partial slabs chengming.zhou
2023-10-24  9:33 ` [RFC PATCH v3 1/7] slub: Keep track of whether slub is on the per-node partial list chengming.zhou
     [not found]   ` <6d054dbe-c90d-591d-11ca-b9ad3787683d@suse.cz>
2023-10-28  1:30     ` Chengming Zhou
2023-10-24  9:33 ` [RFC PATCH v3 2/7] slub: Prepare __slab_free() for unfrozen partial slab out of node " chengming.zhou
     [not found]   ` <43da5c9a-aeff-1bff-81a8-4611470c2514@suse.cz>
2023-10-28  1:35     ` Chengming Zhou
2023-10-24  9:33 ` [RFC PATCH v3 3/7] slub: Reflow ___slab_alloc() chengming.zhou
2023-10-24  9:33 ` [RFC PATCH v3 4/7] slub: Change get_partial() interfaces to return slab chengming.zhou
2023-10-30 16:55   ` Vlastimil Babka
2023-10-31  2:22     ` Chengming Zhou
2023-10-24  9:33 ` [RFC PATCH v3 5/7] slub: Introduce freeze_slab() chengming.zhou
2023-10-30 18:11   ` Vlastimil Babka
2023-10-24  9:33 ` [RFC PATCH v3 6/7] slub: Delay freezing of partial slabs chengming.zhou
2023-10-24 14:30   ` kernel test robot
2023-10-24 14:42     ` Chengming Zhou
2023-10-24 15:22   ` kernel test robot
2023-10-25  2:18   ` Chengming Zhou
2023-10-26  5:49   ` kernel test robot
2023-10-26  7:41     ` Chengming Zhou
2023-10-31  9:50   ` Vlastimil Babka [this message]
2023-10-24  9:33 ` [RFC PATCH v3 7/7] slub: Optimize deactivate_slab() chengming.zhou
2023-10-31 11:15   ` Vlastimil Babka
2023-10-31 11:41     ` Chengming Zhou
2023-10-27 17:57 ` [RFC PATCH v3 0/7] slub: Delay freezing of CPU partial slabs Christoph Lameter
2023-10-28  2:36   ` Chengming Zhou
2023-10-30 16:19     ` Vlastimil Babka
2023-10-31  2:29       ` Chengming Zhou
2023-10-30 19:25     ` Christoph Lameter
2023-10-31  2:50       ` Chengming Zhou
2023-10-31  3:47         ` Christoph Lameter
2023-10-31  4:57           ` Chengming Zhou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6257318a-3d39-ccdf-a85f-dc1008a8f425@suse.cz \
    --to=vbabka@suse.cz \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=chengming.zhou@linux.dev \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=zhouchengming@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.