Re: 2.6.12 Performance problems
From: Danial Thom (danial_thom_at_yahoo.com)
Date: 08/22/05
- Previous message: David S. Miller: "Re: CONFIG_PRINTK_TIME woes"
- Maybe in reply to: Danial Thom: "2.6.12 Performance problems"
- Next in thread: Adrian Bunk: "Re: 2.6.12 Performance problems"
- Reply: Adrian Bunk: "Re: 2.6.12 Performance problems"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 22 Aug 2005 08:41:11 -0700 (PDT) To: linux-kernel@vger.kernel.org
*confused by the top-posting..*
--- Luigi Genoni
<genoni@darkstar.linuxpratico.net> wrote:
> maybe it is possible to be more clear.
>
> voluntary kernel preemption adds explicit
> preemption points into the
> kernel and full kernel preemption makes all
> kernel code preemptible. This
> way even when a process is executing some
> syscall in kernel space, it can
> be volontary or involontary preempted.
>
> For interactive users the systems seems to be
> smarter, but when the system
> is doing a lot of work in kernel space, then
> you of course have to lose
> something.
>
> Also just to check id it's the case or not to
> preempt means you lose
> something. This something is usually troughput.
> In your case I would not
> use a preemptible kernel.
>
> SOmething similar could be said about Timer
> frequency, but here the lost
> is connected to the number to interrupts you
> have to manage.
>
> The point is that a desktop where the users
> simple need a smooth sysstem
> to be userd interactivelly, but not real CPU
> power, and a server where you
> need hourse power are different topics and need
> different kernel
> behaviour.
>
>
>
> On Sun, August 21, 2005 19:07, Danial Thom
> 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?
> >
> > Danial
The issue I have with that logic is that you seem
to use "kernel" in a general sense without regard
to what its doing. Dropping packets is always
detrimental to the user regardless of what he's
using the computer for. An audio stream that
drops packets isn't going to be "smooth" at the
user level.
All of this aside, I need to measure the raw
capabilities of the kernel. With 'bsd OSes I can
tell what the breaking point is by driving the
machine to livelock. Linux seems to have a soft,
floating capacity in that it will drop packets
here and there for no isolatable reason. I'm
having difficulty making a case for its use in a
networking appliance, as dropped packets are not
acceptable. How do I tune the "its ok to drop
packets when x occurs" algorithm to be "its never
ok to drop packets unless x occurs" (such as a
queue depth)? Is it possible?
Danial
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
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/
- Previous message: David S. Miller: "Re: CONFIG_PRINTK_TIME woes"
- Maybe in reply to: Danial Thom: "2.6.12 Performance problems"
- Next in thread: Adrian Bunk: "Re: 2.6.12 Performance problems"
- Reply: Adrian Bunk: "Re: 2.6.12 Performance problems"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
