All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chengming Zhou <chengming.zhou@linux.dev>
To: Christoph Lameter <cl@linux.com>, vbabka@suse.cz
Cc: penberg@kernel.org, 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 0/7] slub: Delay freezing of CPU partial slabs
Date: Tue, 31 Oct 2023 10:50:33 +0800	[thread overview]
Message-ID: <1dcc9969-da5b-4384-96d8-d03c835f198e@linux.dev> (raw)
In-Reply-To: <7f70d130-c05a-3cb7-9509-41c21c3014fb@linux.com>

On 2023/10/31 03:25, Christoph Lameter wrote:
> On Sat, 28 Oct 2023, Chengming Zhou wrote:
> 
>> 2. But for full slab (slab->freelist == NULL), PG_workingset is not much useful, we don't
>>   safely know whether it's used as the cpu slab or not just from this flag. So __slab_free()
>>   still rely on the "frozen" bit to know it.
>>
>> 3. And the maintaining of "frozen" has no extra cost now, since it's changed together with "freelist"
>>   and other counter using cmpxchg, we already have the cmpxchg when start to use a slab as the cpu slab.
>>
>> Maybe I missed something, I don't know how to drop the frozen flag.
> 
> 
> Maybe frozen is now = PG_Workingset | cmpxchg-frozen?
> 
> 

The current scheme (which this series implemented) is:

- node partial slabs: PG_Workingset (set or clear with per-node list_lock protection)
- cpu partial slabs: !PG_Workingset
- cpu slabs: !PG_Workingset && frozen (set or clear using cmpxchg together with freelist)
- full slabs: !PG_Workingset

As Vlastimil noted, it's possible to drop "frozen" bit for cpu slabs, but
we keep it for performance, since we don't need to grab node list_lock to
check whether PG_Workingset is set or not if the "frozen" bit is set.

Thanks!

  reply	other threads:[~2023-10-31  2:51 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
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 [this message]
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=1dcc9969-da5b-4384-96d8-d03c835f198e@linux.dev \
    --to=chengming.zhou@linux.dev \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --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=vbabka@suse.cz \
    --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.