From: Benjamin LaHaise <bcrl@kvack.org>
To: David Miller <davem@davemloft.net>
Cc: johnpol@2ka.mipt.ru, netdev@vger.kernel.org
Subject: Re: [1/4] kevent: core files.
Date: Fri, 23 Jun 2006 17:53:14 -0400 [thread overview]
Message-ID: <20060623215314.GG14126@kvack.org> (raw)
In-Reply-To: <20060623.135423.115910361.davem@davemloft.net>
On Fri, Jun 23, 2006 at 01:54:23PM -0700, David Miller wrote:
> From: Benjamin LaHaise <bcrl@kvack.org>
> Date: Fri, 23 Jun 2006 16:31:14 -0400
>
> > Eh? Nobody has posted any numbers comparing the approaches yet, so this
> > is pure handwaving, unless you have real concrete results?
>
> Evgeniy posts numbers and performance graphs on his kevent work all
> the time.
But you're argueing that the performance of something that hasn't been
tested is worse simply by nature of it not having been tested. That's a
fallacy of omission, iiuc.
> Van Jacobson did in his LCA2006 net channel slides too, perhaps you
> missed that.
I have yet to be convinced that the layering violation known as net channels
is the right way to go, mostly because it breaks horribly in a few cases --
think what happens during periods of CPU overcommit, in which case doing too
much in interrupt context will kill a system (which is why softirqs are
needed). The effect of doing all processing in user context creates issues
with delayed acks (due to context switching to other tasks in the system),
which will cause excess retransmits. The hard problems associated with
packet filtering and security are also still unresolved, which is okay for
a paper, but a concern in real life.
There are also a number of performance flaws in the current stack that
show up under profiling, some of which I posted fixes for, some of which
have yet to be fixed. The pushf/popf pipeline stall was one of the bigger
instances of CPU wastage that Van Jacobson noticed (it shows up as bottom
halves using lots of CPU). Iirc, Ingo's real time patches may avoid that
by way of reworking the irq disable/enable mechanism, which would mean the
results need retesting. Using the cr8 register to enable/disable
interrupts on x86-64 might also improve things, as that would eliminate the
flags dependancy of cli/sti...
In short, there's a lot of work that still has to be done.
-ben
--
"Time is of no importance, Mr. President, only life is important."
Don't Email: <dont@kvack.org>.
next prev parent reply other threads:[~2006-06-23 21:53 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-22 17:14 [1/1] Kevent subsystem Evgeniy Polyakov
2006-06-22 19:01 ` James Morris
2006-06-23 5:54 ` Evgeniy Polyakov
2006-06-22 19:53 ` Robert Iakobashvili
2006-06-23 5:50 ` Evgeniy Polyakov
2006-06-23 6:12 ` YOSHIFUJI Hideaki / 吉藤英明
2006-06-23 6:14 ` David Miller
2006-06-23 6:18 ` YOSHIFUJI Hideaki / 吉藤英明
2006-06-23 7:09 ` [1/4] kevent: core files Evgeniy Polyakov
2006-06-23 18:44 ` Benjamin LaHaise
2006-06-23 19:24 ` Evgeniy Polyakov
2006-06-23 19:55 ` Benjamin LaHaise
2006-06-23 20:17 ` Evgeniy Polyakov
2006-06-23 20:44 ` Benjamin LaHaise
2006-06-23 21:08 ` Evgeniy Polyakov
2006-06-23 21:31 ` Benjamin LaHaise
2006-06-23 21:43 ` Evgeniy Polyakov
2006-06-23 20:19 ` David Miller
2006-06-23 20:31 ` Benjamin LaHaise
2006-06-23 20:54 ` Evgeniy Polyakov
2006-06-24 9:14 ` Robert Iakobashvili
2006-06-23 20:54 ` David Miller
2006-06-23 21:53 ` Benjamin LaHaise [this message]
2006-06-23 22:12 ` David Miller
2006-06-23 7:09 ` [2/4] kevent: network notifications Evgeniy Polyakov
2006-06-23 7:09 ` [3/4] kevent: fs/aio notifications Evgeniy Polyakov
2006-06-23 7:09 ` [4/4] kevent: generic poll and timer notifications Evgeniy Polyakov
-- strict thread matches above, loose matches on Subject: below --
2006-07-26 9:18 [0/4] kevent: generic event processing subsystem Evgeniy Polyakov
2006-07-26 9:18 ` [1/4] kevent: core files Evgeniy Polyakov
2006-07-26 10:31 ` Andrew Morton
2006-07-26 10:37 ` Evgeniy Polyakov
2006-07-26 10:44 ` Evgeniy Polyakov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060623215314.GG14126@kvack.org \
--to=bcrl@kvack.org \
--cc=davem@davemloft.net \
--cc=johnpol@2ka.mipt.ru \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).