lkml.org 
[lkml]   [2023]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH 4/4] mm/slab: move slab merge from slab_common.c to slub.c
    Date


    > -----Original Message-----
    > From: owner-linux-mm@kvack.org <owner-linux-mm@kvack.org> On Behalf Of Vlastimil
    > Babka
    > Sent: Tuesday, November 21, 2023 6:03 PM
    > To: Hyeonggon Yoo <42.hyeyoo@gmail.com>; sxwjean@me.com
    > Cc: cl@linux.com; penberg@kernel.org; rientjes@google.com; iamjoonsoo.kim@lge.com;
    > roman.gushchin@linux.dev; corbet@lwn.net; linux-mm@kvack.org; linux-
    > doc@vger.kernel.org; linux-kernel@vger.kernel.org
    > 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@me.com> wrote:
    > >>
    > >> From: Xiongwei Song <xiongwei.song@windriver.com>
    > >>
    > >> 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

    \
     
     \ /
      Last update: 2023-11-22 06:30    [W:4.294 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site