linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Xiongwei Song <sxwjean@gmail.com>, Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc: Xiongwei Song <sxwjean@me.com>, Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Muchun Song <songmuchun@bytedance.com>,
	"linux-mm @ kvack . org" <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Xiongwei Song <xiongwei.song@windriver.com>
Subject: Re: [PATCH v2] mm/slub: Simplify __kmem_cache_alias()
Date: Wed, 15 Jun 2022 10:37:00 +0200	[thread overview]
Message-ID: <e5ebc952-af17-321f-5343-bc914d47c931@suse.cz> (raw)
In-Reply-To: <CAEVVKH_WM321zQPC-xjchqjySi4kngo6CFz-A6HY2tCjNCZ3SA@mail.gmail.com>

On 6/5/22 09:04, Xiongwei Song wrote:
> On Sat, Jun 4, 2022 at 5:43 PM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
>>
>> On Fri, Jun 03, 2022 at 10:35:55PM +0800, sxwjean@me.com wrote:
>> > From: Xiongwei Song <xiongwei.song@windriver.com>
>> >
>> > There is no need to do anything if sysfs_slab_alias() return nonzero
>> > value after getting a mergeable cache.
>> >
>> > Signed-off-by: Xiongwei Song <xiongwei.song@windriver.com>
>> > Reviewed-by: Muchun Song <songmuchun@bytedance.com>
>> > ---
>> > v2: Collect Reviewed-by tag from Muchun.

Hmm I added v1 (with the Reviewed tag) before getting to the v2 thread. But
I think it's fine, see below.

>> > ---
>> >  mm/slub.c | 8 +++-----
>> >  1 file changed, 3 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/mm/slub.c b/mm/slub.c
>> > index d8d5abf49f5f..9444277d669a 100644
>> > --- a/mm/slub.c
>> > +++ b/mm/slub.c
>> > @@ -4861,6 +4861,9 @@ __kmem_cache_alias(const char *name, unsigned int size, unsigned int align,
>> >
>> >       s = find_mergeable(size, align, flags, name, ctor);
>> >       if (s) {
>> > +             if (sysfs_slab_alias(s, name))
>> > +                     return NULL;
>> > +
>> >               s->refcount++;
>> >
>>
>> I think we should not expose sysfs attributes before initializing
>> what can be read via sysfs attribute (object_size).

Hmm I don't think they are unitialized. They have an old value from the
cache we are merging with, which is updated if the new aliased cache has a
larger one.
So yeah we might briefly during creation expose an alias that will have an
incorrect value, but I doubt anything will break. The values are not stable
anyway as new aliases are added, as we are bumping them for the 'root' cache
and all aliases that share it already.

>> >               /*
>> > @@ -4869,11 +4872,6 @@ __kmem_cache_alias(const char *name, unsigned int size, unsigned int align,
>> >                */
>> >               s->object_size = max(s->object_size, size);
>>
>> this calculation should be done before sysfs_slab_alias().
> 
> Yeah, understood. Should we restore s->object_size and s->inuse if
> sysfs_slab_alias() returns non zero value?

And by bailing out early this patch effectively achieves that, so I'd say
it's a better state than before the patch so I'll keep it unless proven
otherwise. Thanks!

> Regards,
> Xiongwwei
> 
>>
>> Thanks,
>> Hyeonggon
>>
>> >               s->inuse = max(s->inuse, ALIGN(size, sizeof(void *)));
>> > -
>> > -             if (sysfs_slab_alias(s, name)) {
>> > -                     s->refcount--;
>> > -                     s = NULL;
>> > -             }
>> >       }
>> >
>> >       return s;
>> > --
>> > 2.30.2
>> >
>>



  parent reply	other threads:[~2022-06-15  8:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-03 14:35 sxwjean
2022-06-04  9:42 ` Hyeonggon Yoo
2022-06-05  7:04   ` Xiongwei Song
2022-06-14  8:51     ` Hyeonggon Yoo
2022-06-15  8:37     ` Vlastimil Babka [this message]
2022-06-15 11:09       ` Xiongwei Song

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=e5ebc952-af17-321f-5343-bc914d47c931@suse.cz \
    --to=vbabka@suse.cz \
    --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=songmuchun@bytedance.com \
    --cc=sxwjean@gmail.com \
    --cc=sxwjean@me.com \
    --cc=xiongwei.song@windriver.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox