lkml.org 
[lkml]   [2022]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 08/10] mm/slab: Allow dynamic kmalloc() minimum alignment
    On Thu, Apr 07, 2022 at 06:18:16PM +0900, Hyeonggon Yoo wrote:
    > On Thu, Apr 07, 2022 at 09:50:23AM +0100, Catalin Marinas wrote:
    > > On Thu, Apr 07, 2022 at 03:46:37AM +0000, Hyeonggon Yoo wrote:
    > > > On Tue, Apr 05, 2022 at 02:57:56PM +0100, Catalin Marinas wrote:
    > > > > --- a/mm/slab_common.c
    > > > > +++ b/mm/slab_common.c
    > > > > @@ -838,9 +838,18 @@ void __init setup_kmalloc_cache_index_table(void)
    > > > > }
    > > > > }
    > > > >
    > > > > -static void __init
    > > > > +unsigned int __weak arch_kmalloc_minalign(void)
    > > > > +{
    > > > > + return ARCH_KMALLOC_MINALIGN;
    > > > > +}
    > > > > +
    > > >
    > > > As ARCH_KMALLOC_ALIGN and arch_kmalloc_minalign() may not be same after
    > > > patch 10, I think s/ARCH_KMALLOC_ALIGN/arch_kmalloc_minalign/g
    > > > for every user of it would be more correct?
    > >
    > > Not if the code currently using ARCH_KMALLOC_MINALIGN needs a constant.
    > > Yes, there probably are a few places where the code can cope with a
    > > dynamic arch_kmalloc_minalign() but there are two other cases where a
    > > constant is needed:
    > >
    > > 1. As a BUILD_BUG check because the code is storing some flags in the
    > > bottom bits of a pointer. A smaller ARCH_KMALLOC_MINALIGN works just
    > > fine here.
    > >
    > > 2. As a static alignment for DMA requirements. That's where the newly
    > > exposed ARCH_DMA_MINALIGN should be used.
    > >
    > > Note that this series doesn't make the situation any worse than before
    > > since ARCH_DMA_MINALIGN stays at 128 bytes for arm64. Current users can
    > > evolve to use a dynamic alignment in future patches. My main aim with
    > > this series is to be able to create kmalloc-64 caches on arm64.
    >
    > AFAIK there are bunch of drivers that directly calls kmalloc().

    Well, lots of drivers call kmalloc() ;).

    > It becomes tricky when e.g.) a driver allocates just 32 bytes,
    > but architecture requires it to be 128-byte aligned.

    That's the current behaviour, a 32 byte allocation would return an
    object from kmalloc-128. I want to reduce this to at least kmalloc-64
    (or smaller) if the CPU/SoC allows it.

    > That's why everything allocated from kmalloc() need to be aligned in
    > ARCH_DMA_MINALIGN.

    I don't get your conclusion here. Would you mind explaining?

    > So I'm yet skeptical on decoupling ARCH_DMA/KMALLOC_MINALIGN. Instead
    > of decoupling it, I'm more into dynamically decreasing it.

    The reason for decoupling is mostly that there are some static uses of
    ARCH_KMALLOC_MINALIGN as per point 1 above. The other is the
    __assume_kmalloc_alignment attribute. We shouldn't have such assumed
    alignment larger than what a dynamic kmalloc() would return. To me it
    makes a lot more sense for ARCH_KMALLOC_MINALIGN to be the minimum
    guaranteed in a kernel build but kmalloc() returning a larger alignment
    at run-time than the other way around.

    Thanks.

    --
    Catalin

    \
     
     \ /
      Last update: 2022-04-07 17:31    [W:4.046 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site