> -----Original Message-----
> From: owner-linux-mm@xxxxxxxxx <owner-linux-mm@xxxxxxxxx> On Behalf Of Vlastimil
> Babka
> Sent: Tuesday, November 21, 2023 6:03 PM
> To: Hyeonggon Yoo <42.hyeyoo@xxxxxxxxx>; sxwjean@xxxxxx
> Cc: cl@xxxxxxxxx; penberg@xxxxxxxxxx; rientjes@xxxxxxxxxx; iamjoonsoo.kim@xxxxxxx;
> roman.gushchin@xxxxxxxxx; corbet@xxxxxxx; linux-mm@xxxxxxxxx; linux-
> doc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH 4/4] mm/slab: move slab merge from slab_common.c to slub.c
>
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the
> content is safe.
>
> On 11/21/23 09:54, Hyeonggon Yoo wrote:
> > On Mon, Nov 20, 2023 at 6:13 PM <sxwjean@xxxxxx> wrote:
> >>
> >> From: Xiongwei Song <xiongwei.song@xxxxxxxxxxxxx>
> >>
> >> Since slab allocator has been removed. There is no users about slab
> >> merge except slub. This commit is almost to revert
> >> commit 423c929cbbec ("mm/slab_common: commonize slab merge logic").
> >>
> >> Also change all prefix of slab merge related functions, variables and
> >> definitions from "slab/SLAB" to"slub/SLUB".
> >
> > Could you please elaborate a little bit?
> > I am not sure if I understand what the last two patches of this series
> > are useful for.
> >
> > - Why rename variable/function/macro names?
> > - Why move merge related functions from slab_common.c to slub.c?
>
> In my series I have moved functions that were part of allocation/free hot
> paths as there should be performance benefits if they are all in the same
> compilation unit.
>
> > (I mean merging slab_common.c and slub.c into single file might make sense
> > but why move only some parts of one into the other?)
>
> OTOH slub.c becomes quite big, so I think it would make sense to not merge
> mm/slab_common.c fully. The non-hot code that's handling e.g. the caches
> creation and management, such as what this patch is moving, could certainly
> stay away from mm/slub.c. We could just pick a more descriptive name for
> slab_common.c.
>
> I'd even investigate if more parts of slub.c could be split out (to a new
> file/files) without compromising the hot paths, i.e. sysfs, debugging etc.
Ok, sure. Sounds good.
Regards,
Xiongwei
