lkml.org 
[lkml]   [2008]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

    * Eric Dumazet <dada1@cosmosbay.com> wrote:

    > Ingo Molnar a écrit :
    >> * Christoph Lameter <cl@linux-foundation.org> wrote:
    >>
    >>> hmmm... Well we are almost there.
    >>>
    >>> 2.6.22:
    >>>
    >>> Throughput 2526.15 MB/sec 8 procs
    >>>
    >>> 2.6.28-rc5:
    >>>
    >>> Throughput 2486.2 MB/sec 8 procs
    >>>
    >>> 8p Dell 1950 and the number of processors specified on the tbench
    >>> command line.
    >>
    >> And with net-next we might even be able to get past that magic limit?
    >> net-next is linus-latest plus the latest and greatest networking bits:
    >>
    >> $ cat .git/config
    >>
    >> [remote "net-next"]
    >> url = git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git
    >> fetch = +refs/heads/*:refs/remotes/net-next/*
    >>
    >> ... so might be worth a test. Just to satisfy our curiosity and to
    >> possibly close the entry :-)
    >>
    >
    > Well, bits in net-next are new stuff for 2.6.29, not really
    > regression fixes, but yes, they should give nice tbench speedups.

    yeah, i know - technically these are lots-of-kernel-releases effects
    so not bona fide latest-cycle regressions anyway. But it doesnt matter
    how we call them, we want improvement in these metrics.

    > Now, I wish sockets and pipes not going through dcache, not tbench
    > affair of course but real workloads...
    >
    > running 8 processes on a 8 way machine doing a
    >
    > for (;;)
    > close(socket(AF_INET, SOCK_STREAM, 0));
    >
    > is slow as hell, we hit so many contended cache lines ...
    >
    > ticket spin locks are slower in this case (dcache_lock for example
    > is taken twice when we allocate a socket(), once in d_alloc(),
    > another one in d_instantiate())

    hm, weird - since there's no real VFS namespace impact i fail to
    realize the fundamental need that causes us to hit the dcache_lock.
    (perhaps there's none and this is fixable)

    The general concept of mapping sockets to fds is a fundamental and
    powerful abstraction. There are APIs that also connect them to the VFS
    namespace (such as unix domain sockets) - but those should be special
    cases, not impacting normal TCP sockets.

    Ingo
    --
    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: 2008-11-21 10:21    [W:0.025 / U:61.800 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site