lkml.org 
[lkml]   [2010]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH net-next] net: allocate skbs on local node
    On Thu, 14 Oct 2010, Pekka Enberg wrote:

    > Argh. Why would we want to introduce something that's effectively a new
    > allocator based on SLUB? If there's something controversial in the current
    > patch series, lets just keep it out of mainline. A "rewrite" is the reason
    > we're in this mess so lets not repeat the same mistake again!
    >

    SLUB is a good base framework for developing just about any slab allocator
    you can imagine, in part because of its enhanced debugging facilities.
    Nick originally developed SLQB with much of the same SLUB framework and
    the queueing changes that Christoph is proposing in his new unified
    allocator builds upon SLUB.

    Instead of the slab.c, slab_queue.c, and slab_nonqueue.c trifecta, I
    suggested building as much of the core allocator into a single file as
    possible and then extending that with a config option such as
    CONFIG_SLAB_QUEUEING, if possible. Christoph knows his allocator better
    than anybody so he'd be the person to ask if this was indeed feasible and,
    if so, I think it's in the best interest of a long-term maintainable
    kernel.

    I care about how this is organized because I think the current config
    option demanding users select between SLAB and SLUB without really
    understanding the differences (especially for users who run a very wide
    range of applications and the pros and cons of better microbenchmark
    results for one allocator over another isn't at all convincing) is
    detrimental.


    \
     
     \ /
      Last update: 2010-10-14 09:25    [W:0.022 / U:30.556 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site