lkml.org 
[lkml]   [2005]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.12 Performance problems


    --- Jesper Juhl <jesper.juhl@gmail.com> wrote:

    > On 8/21/05, Jesper Juhl <jesper.juhl@gmail.com>
    > wrote:
    > > On 8/21/05, Danial Thom
    > <danial_thom@yahoo.com> wrote:
    > > > >
    > > > Ok, well you'll have to explain this one:
    > > >
    > > > "Low latency comes at the cost of decreased
    > > > throughput - can't have both"
    > > >
    > > > Seems to be a bit backwards. Threading the
    > kernel
    > > > adds latency, so its the additional latency
    > in
    > > > the kernel that causes the drop in
    > throughput. Do
    > > > you mean that kernel performance has been
    > > > sacrificed in order to be able to service
    > other
    > > > threads more quickly, even when there are
    > no
    > > > other threads to be serviced?
    > > >
    > >
    > > Ok, let me start with the way HZ influences
    > things.
    > >
    > [snip]
    >
    > A small followup.
    >
    > I'm not saying that the value of HZ or your
    > preempt setting (whatever
    > it may be) is definately the cause of your
    > problem. All I'm saying is
    > that it might be a contributing factor, so it's
    > probably something
    > that's worth a little bit of time testing.
    >
    > In many cases people running a server on
    > resonably new hardware with
    > HZ=1000 and full preempt won't even notice, but
    > that's depending on
    > the load on the server and what jobs it has.
    > For some tasks it
    > matters, for some the differences in
    > performance is negligible.
    >
    > You problem could very well be something else
    > entirely, but try a
    > kernel build with PREEMPT_NONE and HZ=100 and
    > see if it makes a big
    > difference (or if that's your current config,
    > then try the opposite,
    > HZ=1000 and PREEMPT). If it does make a
    > difference, then that's a
    > valuable piece of information to report on the
    > list. If it turns out
    > it makes next to no difference at all, then
    > that as well is relevant
    > information as then people will know that HZ &
    > preempt is not the
    > cause and can focus on finding the problem
    > elsewhere.
    >
    Yes. Hz isn't going to make much difference on a
    2.0Ghz opteron, but I can see how premption can
    cause packet loss. Shouldn't packet processing be
    the highest priority process? It seems pointless
    to "keep the audio buffers full" if you're
    dropping packets as a result.

    Also some clown typing on the keyboard shouldn't
    cause packet loss. Trading network integrity for
    snappy responsiveness is a bad trade.

    Danial



    __________________________________
    Yahoo! Mail for Mobile
    Take Yahoo! Mail with you! Check email on your mobile phone.
    http://mobile.yahoo.com/learn/mail
    -
    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: 2005-08-21 23:15    [W:0.029 / U:0.184 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site