lkml.org 
[lkml]   [2008]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] procfs: provide slub's /proc/slabinfo
    On Fri, 4 Jan 2008, Matt Mackall wrote:

    > > needs to know the size. So it is not possible in SLOB to use
    > > kmem_cache_alloc on an object and then free it using kfree?
    >
    > Indeed. Mismatching allocator and deallocator is bug, even if it happens
    > to work for SLAB/SLUB.

    Was the kernel audited for this case? I saw some rather scary uses of slab
    objects for I/O purposes come up during SLUB development.

    > Yes. You've got (most of) a fix. It's overly-complicated and SLOB
    > doesn't need it. How many ways do I need to say this?

    So SLOB is then not able to compact memory after an updatedb run? The
    memory must stay dedicated to slab uses. SLOB memory can be filled
    up with objects of other slab types but it cannot be reused for page
    cache and anonymous pages etc. Slab defrag is freeing memory back to the
    page allocator with SLUB. That is *not* provided by SLOB. Could be made to
    work though.

    > > Well that increase if you need to align the object. For kmalloc this
    > > usually means cache line align a power of two object right? So we have a
    > > cacheline size of overhead?
    >
    > a) alignment doesn't increase memory use because the memory before the
    > object is still allocatable

    Ok so we end up with lots of small holes on a list that has to be scanned
    to find free memory?

    > b) kmallocs aren't aligned!

    From mm/slob.c:

    #ifndef ARCH_KMALLOC_MINALIGN
    #define ARCH_KMALLOC_MINALIGN __alignof__(unsigned long)
    #endif

    void *__kmalloc_node(size_t size, gfp_t gfp, int node)
    {
    unsigned int *m;
    int align = max(ARCH_KMALLOC_MINALIGN, ARCH_SLAB_MINALIGN);

    (IMHO it would be safer to set the minimum default to __alignof__(unsigned
    long long) like SLAB/SLUB).



    Ok. So lets try a worst case scenario. If we do a 128 byte kmalloc then we
    can allocate the following number of object from one 4k slab

    SLUB 32 (all memory of the 4k page is used for 128 byte objects)
    SLAB 29/30 (management structure occupies first two/three objects)
    SLOB 30(?) (Alignment results in object being 136 byte of effective size,
    we have 16 bytes leftover that could be used for a
    very small allocation. Right?)


    \
     
     \ /
      Last update: 2008-01-04 22:39    [W:2.824 / U:0.144 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site