All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chengming Zhou <chengming.zhou@linux.dev>
To: Vlastimil Babka <vbabka@suse.cz>, 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 1/7] slub: Keep track of whether slub is on the per-node partial list
Date: Sat, 28 Oct 2023 09:30:54 +0800	[thread overview]
Message-ID: <b3f0e14f-03df-44e3-a524-4ed43cb8f980@linux.dev> (raw)
In-Reply-To: <6d054dbe-c90d-591d-11ca-b9ad3787683d@suse.cz>

On 2023/10/27 23:09, Vlastimil Babka wrote:
> On 10/24/23 11:33, chengming.zhou@linux.dev wrote:
>> From: Chengming Zhou <zhouchengming@bytedance.com>
>>
>> Now we rely on the "frozen" bit to see if we should manipulate the
>> slab->slab_list, which will be changed in the following patch.
>>
>> Instead we introduce another way to keep track of whether slub is on
>> the per-node partial list, here we reuse the PG_workingset bit.
>>
>> We use __set_bit and __clear_bit directly instead of the atomic version
>> for better performance and it's safe since it's protected by the slub
>> node list_lock.
>>
>> Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com>
>> ---
>>  mm/slab.h | 19 +++++++++++++++++++
>>  mm/slub.c |  3 +++
>>  2 files changed, 22 insertions(+)
>>
>> diff --git a/mm/slab.h b/mm/slab.h
>> index 8cd3294fedf5..50522b688cfb 100644
>> --- a/mm/slab.h
>> +++ b/mm/slab.h
> 
> I think these helper might just go to mm/slub.c as nothing else would use them.
> 

Ok.

>> @@ -193,6 +193,25 @@ static inline void __slab_clear_pfmemalloc(struct slab *slab)
>>  	__folio_clear_active(slab_folio(slab));
>>  }
>>  
>> +/*
>> + * Slub reuse PG_workingset bit to keep track of whether it's on
> 
> "SLUB reuses" ...
> 
> Looks fine otherwise!
> 

Will fix it. Thanks!

  parent reply	other threads:[~2023-10-28  1:31 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 [this message]
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
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=b3f0e14f-03df-44e3-a524-4ed43cb8f980@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.