[PATCH] procfs: provide slub's /proc/slabinfo - Kernel

This is a discussion on [PATCH] procfs: provide slub's /proc/slabinfo - Kernel ; > Finally getting rid of SLAB is a much trickier proposition because SLUB > still loses in a few important corner cases. The big issue is that we haven't really made much progress on at least some of these test ...

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4
Results 61 to 68 of 68

Thread: [PATCH] procfs: provide slub's /proc/slabinfo

  1. Re: [RFC PATCH] greatly reduce SLOB external fragmentation

    > Finally getting rid of SLAB is a much trickier proposition because SLUB
    > still loses in a few important corner cases.


    The big issue is that we haven't really made much progress on at least
    some of these test cases (like the database benchmarks) for quite some
    time (and that wasn't for a lack of trying) :-/ Might be a fundamental
    problem.

    -Andi
    --
    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/

  2. Re: [RFC PATCH] greatly reduce SLOB external fragmentation

    Matt Mackall wrote:

    > Finally getting rid of SLAB is a much trickier proposition because SLUB
    > still loses in a few important corner cases.


    Which corner cases? I know about the reports on the TPC issue which I guess is a result of the avoidance of queueing in the cold free case. It would be good to have a small C program (under an open source license) that shows the issue.




    --
    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/

  3. Re: [RFC PATCH] greatly reduce SLOB external fragmentation

    Andi Kleen wrote:
    >> Finally getting rid of SLAB is a much trickier proposition because SLUB
    >> still loses in a few important corner cases.

    >
    > The big issue is that we haven't really made much progress on at least
    > some of these test cases (like the database benchmarks) for quite some
    > time (and that wasn't for a lack of trying) :-/ Might be a fundamental
    > problem.


    It would be good to have more of these benchmark regressions than just TPC which requires a database setup etc etc. Preferably something that is easily runnable by everyone.

    There is a fundamental difference in how frees are handled. Slub is queueless so it must use an atomic operation on the page struct of the slab that we free to (in the case that the freeing does not occur to the current cpu slab) to serialize access.

    SLAB can avoid that by just stuffing the pointer to the object to be freed into a per cpu queue. Then later the queue is processed and the objects are merged into the slabs. But the later workqueue processing then causes run time variabilities which impact network performance and cause latencies. And the queuing only works in the SMP case. In the NUMA case we need to first check the locality of the object and then stuff it into alien queues (if its not local node). Then we need to expire the alien queues at some point. We have these alien queues per node which means they require locks and we have NODES * CPUS of them.



    --
    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/

  4. Re: [RFC PATCH] greatly reduce SLOB external fragmentation


    On Thu, 2008-07-31 at 09:26 -0500, Christoph Lameter wrote:
    > Matt Mackall wrote:
    >
    > > Finally getting rid of SLAB is a much trickier proposition because SLUB
    > > still loses in a few important corner cases.

    >
    > Which corner cases? I know about the reports on the TPC issue which I
    > guess is a result of the avoidance of queueing in the cold free case.
    > It would be good to have a small C program (under an open source
    > license) that shows the issue.


    That's the one I had in mind, which I have no personal insight into.

    --
    Mathematics is the supreme nostalgia of our time.

    --
    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/

  5. Re: [RFC PATCH] greatly reduce SLOB external fragmentation

    Matt Mackall wrote:
    > On Thu, 2008-07-31 at 09:26 -0500, Christoph Lameter wrote:
    >> Matt Mackall wrote:
    >>
    >>> Finally getting rid of SLAB is a much trickier proposition because SLUB
    >>> still loses in a few important corner cases.

    >> Which corner cases? I know about the reports on the TPC issue which I
    >> guess is a result of the avoidance of queueing in the cold free case.
    >> It would be good to have a small C program (under an open source
    >> license) that shows the issue.

    >
    > That's the one I had in mind, which I have no personal insight into.


    I also only so far had to rely on reports by others and guesswork as to what is going on.


    --
    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/

  6. Re: [RFC PATCH] greatly reduce SLOB external fragmentation

    Andi Kleen wrote:
    > On Thu, Jul 31, 2008 at 10:25:45AM -0500, Christoph Lameter wrote:
    >> Andi Kleen wrote:
    >>>> Finally getting rid of SLAB is a much trickier proposition because SLUB
    >>>> still loses in a few important corner cases.
    >>> The big issue is that we haven't really made much progress on at least
    >>> some of these test cases (like the database benchmarks) for quite some
    >>> time (and that wasn't for a lack of trying) :-/ Might be a fundamental
    >>> problem.

    >> It would be good to have more of these benchmark regressions than just TPC which requires a database setup etc etc. Preferably something that is easily runnable by everyone.

    >
    > AFAIK willy had a small test case for at least one of them.


    He is developing a scsi performance test program that showed a regression but it was proprietary last time I heard of it. Maybe its now available?

    --
    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/

  7. Re: [RFC PATCH] greatly reduce SLOB external fragmentation

    On Thu, Jul 31, 2008 at 10:25:45AM -0500, Christoph Lameter wrote:
    > Andi Kleen wrote:
    > >> Finally getting rid of SLAB is a much trickier proposition because SLUB
    > >> still loses in a few important corner cases.

    > >
    > > The big issue is that we haven't really made much progress on at least
    > > some of these test cases (like the database benchmarks) for quite some
    > > time (and that wasn't for a lack of trying) :-/ Might be a fundamental
    > > problem.

    >
    > It would be good to have more of these benchmark regressions than just TPC which requires a database setup etc etc. Preferably something that is easily runnable by everyone.


    AFAIK willy had a small test case for at least one of them.

    -Andi
    --
    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/

  8. Re: [RFC PATCH] greatly reduce SLOB external fragmentation

    Linus Torvalds writes:

    > On Thu, 31 Jul 2008, Pekka Enberg wrote:
    >>
    >> Oh, I didn't suggest this for merging. Just thought you'd be
    >> interested to know that best-fit doesn't really do that much better
    >> than what we have in the tree now. (Well, I was kinda hoping you'd
    >> tell me why my implementation is wrong and you were right all along.)

    >
    > Heh. Most allocators tend to work pretty well under normal load, and the
    > real fragmentation problems all tend to happen under special patterns. The
    > one in glibc, for example, sucks donkey dick when using threading, but is
    > apparently ok otherwise.
    >
    > I wouldn't actually expect most "normal" kernel use to show any really bad
    > patterns on any normal loads. Google for
    >
    > worst-case first-fit fragmentation
    >
    > (or 'next-fit' for that matter) to see some stuff. Of course, it is scary
    > only if you can trigger it in practice (perhaps with certains games on
    > packet size, or creating/removing files with pathname size patterns ec).
    >
    > [ Of course, google probably mostly returns hits from all those ACM
    > portals etc. I wonder why google does that - they're almost totally
    > useless search results. Sad. If somebody knows how to turn those ACM
    > pay-portals off in google, pls let me know ]
    >
    > Linus


    blahblah -siteortal.acm.org ?

    --
    mailto:av1474@comtv.ru

    --
    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/

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4