lkml.org 
[lkml]   [2008]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [patch 7/7] powerpc: lockless get_user_pages_fast
    On Wed, 11 Jun 2008 06:49:02 +0200 Nick Piggin <npiggin@suse.de> wrote:

    > On Tue, Jun 10, 2008 at 09:41:33PM -0700, Christoph Lameter wrote:
    > > And yes slab defrag is part of linux-next. So it would break.

    No, slab defreg[*] isn't in linux-next.

    y:/usr/src/25> diffstat patches/linux-next.patch| grep mm/slub.c
    mm/slub.c | 4

    That's two spelling fixes in comments.

    I have git-pekka in -mm too. Here it is:

    --- a/mm/slub.c
    +++ b/mm/slub.c
    @@ -2765,6 +2765,7 @@ void kfree(const void *x)

    page = virt_to_head_page(x);
    if (unlikely(!PageSlab(page))) {
    + BUG_ON(!PageCompound(page));
    put_page(page);
    return;
    }

    > Can memory management patches go though mm/? I dislike the cowboy
    > method of merging things that some other subsystems have adopted :)

    I think I'd prefer that. I may be a bit slow, but we're shoving at
    least 100 MM patches through each kernel release and I think I review
    things more closely than others choose to. At least, I find problems
    and I've seen some pretty wild acked-bys...


    [*] It _isn't_ "slab defrag". Or at least, it wasn't last time I saw
    it. It's "slub defrag". And IMO it is bad to be adding slub-only
    features because afaik slub still isn't as fast as slab on some things
    and so some people might want to run slab rather than slub. And
    because if this the decision whether to retain slab or slub STILL
    hasn't been made. Carrying both versions was supposed to be a
    short-term transitional thing :(


    \
     
     \ /
      Last update: 2008-06-11 08:11    [W:3.970 / U:0.736 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site