lkml.org 
[lkml]   [2007]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [15/17] SLUB: Support virtual fallback via SLAB_VFALLBACK
    Date
    On Saturday 29 September 2007 03:33, Christoph Lameter wrote:
    > On Fri, 28 Sep 2007, Nick Piggin wrote:
    > > On Wednesday 19 September 2007 13:36, Christoph Lameter wrote:
    > > > SLAB_VFALLBACK can be specified for selected slab caches. If fallback
    > > > is available then the conservative settings for higher order
    > > > allocations are overridden. We then request an order that can
    > > > accomodate at mininum 100 objects. The size of an individual slab
    > > > allocation is allowed to reach up to 256k (order 6 on i386, order 4 on
    > > > IA64).
    > >
    > > How come SLUB wants such a big amount of objects? I thought the
    > > unqueued nature of it made it better than slab because it minimised
    > > the amount of cache hot memory lying around in slabs...
    >
    > The more objects in a page the more the fast path runs. The more the fast
    > path runs the lower the cache footprint and the faster the overall
    > allocations etc.
    >
    > SLAB can be configured for large queues holdings lots of objects.
    > SLUB can only reach the same through large pages because it does not
    > have queues. One could add the ability to manage pools of cpu slabs but
    > that would be adding yet another layer to compensate for the problem of
    > the small pages. Reliable large page allocations means that we can get rid
    > of these layers and the many workarounds that we have in place right now.

    That doesn't sound very nice because you don't actually want to use up
    higher order allocations if you can avoid it, and you definitely don't want
    to be increasing your slab page size unit if you can help it, because it
    compounds the problem of slab fragmentation.


    > The unqueued nature of SLUB reduces memory requirements and in general the
    > more efficient code paths of SLUB offset the advantage that SLAB can reach
    > by being able to put more objects onto its queues.
    > introduces complexity and cache line use through the need to manage those
    > queues.

    I thought it was slower. Have you fixed the performance regression?
    (OK, I read further down that you are still working on it but not confirmed
    yet...)


    > > vmalloc is incredibly slow and unscalable at the moment. I'm still
    > > working on making it more scalable and faster -- hopefully to a point
    > > where it would actually be usable for this... but you still get moved off
    > > large TLBs, and also have to inevitably do tlb flushing.
    >
    > Again I have not seen any fallbacks to vmalloc in my testing. What we are
    > doing here is mainly to address your theoretical cases that we so far have
    > never seen to be a problem and increase the reliability of allocations of
    > page orders larger than 3 to a usable level. So far I have so far not
    > dared to enable orders larger than 3 by default.

    Basically, all that shows is that your testing isn't very thorough. 128MB
    is an order of magnitude *more* memory than some users have. They
    probably wouldn't be happy with a regression in slab allocator performance
    either.


    > > Or do you have SLUB at a point where performance is comparable to SLAB,
    > > and this is just a possible idea for more performance?
    >
    > AFAICT SLUBs performance is superior to SLAB in most cases and it was like
    > that from the beginning. I am still concerned about several corner cases
    > though (I think most of them are going to be addressed by the per cpu
    > patches in mm). Having a comparable or larger amount of per cpu objects as
    > SLAB is something that also could address some of these concerns and could
    > increase performance much further.

    OK, so long as it isn't going to depend on using higher order pages, that's
    fine. (if they help even further as an optional thing, that's fine too. You
    can turn them on your huge systems and not even bother about adding
    this vmap fallback -- you won't have me to nag you about these
    purely theoretical issues).
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-09-28 23:49    [W:0.028 / U:0.296 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site