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,
	willy@infradead.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 v4 9/9] slub: Update frozen slabs documentations in the source
Date: Wed, 1 Nov 2023 14:51:19 +0100	[thread overview]
Message-ID: <211ac705-5972-9b39-73f1-a608e65b6de3@suse.cz> (raw)
In-Reply-To: <20231031140741.79387-10-chengming.zhou@linux.dev>

On 10/31/23 15:07, chengming.zhou@linux.dev wrote:
> From: Chengming Zhou <zhouchengming@bytedance.com>
> 
> The current updated scheme (which this series implemented) is:
>  - node partial slabs: PG_Workingset && !frozen
>  - cpu partial slabs: !PG_Workingset && !frozen
>  - cpu slabs: !PG_Workingset && frozen
>  - full slabs: !PG_Workingset && !frozen

It could be useful to put this also to the initial comment description.
Towards the end of the comment, there's a block explaining
"slab->frozen". It could be extended to cover all 4 combination (but not
all of them need such long explanation).

> 
> The most important change is that "frozen" bit is not set for the
> cpu partial slabs anymore, __slab_free() will grab node list_lock
> then check by !PG_Workingset that it's not on a node partial list.
> 
> And the "frozen" bit is still kept for the cpu slabs for performance,
> since we don't need to grab node list_lock to check whether the
> PG_Workingset is set or not if the "frozen" bit is set in __slab_free().
> 
> Update related documentations and comments in the source.
> 
> Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com>
> ---
>  mm/slub.c | 16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index bb7368047103..89d3f7a18a73 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -76,13 +76,22 @@
>   *
>   *   Frozen slabs
>   *
> - *   If a slab is frozen then it is exempt from list management. It is not
> - *   on any list except per cpu partial list. The processor that froze the
> + *   If a slab is frozen then it is exempt from list management. It is
> + *   the cpu slab which is actively allocated from by the processor that
> + *   froze it and it is not on any list. The processor that froze the
>   *   slab is the one who can perform list operations on the slab. Other
>   *   processors may put objects onto the freelist but the processor that
>   *   froze the slab is the only one that can retrieve the objects from the
>   *   slab's freelist.
>   *
> + *   CPU partial slabs
> + *
> + *   The partially empty slabs cached on the CPU partial list are used
> + *   for performance reasons, which speeds up the allocation process.
> + *   These slabs are not frozen, but also exempt from list management,

					^ are also

(otherwise somebody could read it as "also are not")

> + *   by clearing the PG_workingset flag when moving out of the node
> + *   partial list. Please see __slab_free() for more details.
> + *
>   *   list_lock
>   *
>   *   The list_lock protects the partial and full list on each node and
> @@ -2620,8 +2629,7 @@ static void put_partials_cpu(struct kmem_cache *s,
>  }
>  
>  /*
> - * Put a slab that was just frozen (in __slab_free|get_partial_node) into a
> - * partial slab slot if available.
> + * Put a slab into a partial slab slot if available.
>   *
>   * If we did not find a slot then simply move all the partials to the
>   * per node partial list.

  reply	other threads:[~2023-11-01 13:51 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-31 14:07 [RFC PATCH v4 0/9] slub: Delay freezing of CPU partial slabs chengming.zhou
2023-10-31 14:07 ` [RFC PATCH v4 1/9] slub: Reflow ___slab_alloc() chengming.zhou
2023-10-31 14:07 ` [RFC PATCH v4 2/9] slub: Change get_partial() interfaces to return slab chengming.zhou
2023-10-31 14:07 ` [RFC PATCH v4 3/9] slub: Keep track of whether slub is on the per-node partial list chengming.zhou
2023-11-01 12:23   ` Vlastimil Babka
2023-10-31 14:07 ` [RFC PATCH v4 4/9] slub: Prepare __slab_free() for unfrozen partial slab out of node " chengming.zhou
2023-11-01 12:26   ` Vlastimil Babka
2023-10-31 14:07 ` [RFC PATCH v4 5/9] slub: Introduce freeze_slab() chengming.zhou
2023-12-03  6:08   ` Hyeonggon Yoo
2023-10-31 14:07 ` [RFC PATCH v4 6/9] slub: Delay freezing of partial slabs chengming.zhou
2023-10-31 14:07 ` [RFC PATCH v4 7/9] slub: Optimize deactivate_slab() chengming.zhou
2023-11-01 13:21   ` Vlastimil Babka
2023-11-02  2:10     ` Chengming Zhou
2023-10-31 14:07 ` [RFC PATCH v4 8/9] slub: Rename all *unfreeze_partials* functions to *put_partials* chengming.zhou
2023-11-01 13:40   ` Vlastimil Babka
2023-11-02  2:12     ` Chengming Zhou
2023-10-31 14:07 ` [RFC PATCH v4 9/9] slub: Update frozen slabs documentations in the source chengming.zhou
2023-11-01 13:51   ` Vlastimil Babka [this message]
2023-11-02  2:48     ` Chengming Zhou
2023-11-01 13:33 ` [RFC PATCH v4 0/9] slub: Delay freezing of CPU partial slabs Hyeonggon Yoo
2023-11-02  2:17   ` Chengming Zhou
2023-11-01 13:59 ` Vlastimil Babka
2023-11-02  2:19   ` 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=211ac705-5972-9b39-73f1-a608e65b6de3@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=willy@infradead.org \
    --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.