lkml.org 
[lkml]   [2014]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH -mm 5/8] slab: remove kmem_cache_shrink retval
    On Fri, May 30, 2014 at 09:49:55AM -0500, Christoph Lameter wrote:
    > On Fri, 30 May 2014, Vladimir Davydov wrote:
    >
    > > First, nobody uses it. Second, it differs across the implementations:
    > > for SLUB it always returns 0, for SLAB it returns 0 if the cache appears
    > > to be empty. So let's get rid of it.
    >
    > Well slub returns an error code if it fails

    ... to sort slabs by the nubmer of objects in use, which is not even
    implied by the function declaration. Why can *shrinking*, which is what
    kmem_cache_shrink must do at first place, ever fail?

    > I am all in favor of making it consistent. The indication in SLAB that
    > the slab is empty may be useful. May return error code or the number
    > of slab pages in use?

    We can, but why if nobody is going to use it?

    > Some of the code that is shared by the allocators here could be moved into
    > mm/slab_common.c. Put kmem_cache_shrink there and then have
    > __kmem_cache_shrink to the allocator specific things?

    Already did in scope of mm-commit 4fabfe86c4a5 ("slab: get_online_mems
    for kmem_cache_{create,destroy,shrink}") :-)

    Thanks.


    \
     
     \ /
      Last update: 2014-05-31 12:41    [W:4.176 / U:1.548 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site