From: Eric Dumazet <eric.dumazet@gmail.com>
To: Li Yu <raise.sail@gmail.com>
Cc: Changli Gao <xiaosuo@gmail.com>,
Linux Netdev List <netdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
davidel@xmailserver.org
Subject: Re: [RFC] Introduce to batch variants of accept() and epoll_ctl() syscall
Date: Fri, 15 Jun 2012 10:51:58 +0200 [thread overview]
Message-ID: <1339750318.7491.70.camel@edumazet-glaptop> (raw)
In-Reply-To: <4FDACA26.70004@gmail.com>
On Fri, 2012-06-15 at 13:37 +0800, Li Yu wrote:
> Of course, I think that implementing them should not be a hard work :)
>
> Em. I really do not know whether it is necessary to introduce to a new
> syscall here. An alternative solution to add new socket option to handle
> such batch requirement, so applications also can detect if kernel has
> this extended ability with a easy getsockopt() call.
>
> Any way, I am going to try to write a prototype first.
Before that, could you post the result of "perf top", or "perf
record ...;perf report"
> The top shows the kernel is most cpu hog, the testing is simple,
> just a accept() -> epoll_ctl(ADD) loop, the ratio of cpu util sys% to
> si% is about 2:5.
This ratio is not meaningful, if we dont know where time is spent.
I doubt epoll_ctl(ADD) is a problem here...
If it is, batching the fds wont speed the thing anyway...
I believe accept() is the problem here, because it contends with the
softirq processing the tcp session handshake.
next prev parent reply other threads:[~2012-06-15 8:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-15 4:13 [RFC] Introduce to batch variants of accept() and epoll_ctl() syscall Li Yu
2012-06-15 4:29 ` Changli Gao
2012-06-15 5:37 ` Li Yu
2012-06-15 8:51 ` Eric Dumazet [this message]
2012-06-18 23:27 ` Andi Kleen
2012-07-06 9:38 ` Li Yu
2012-07-09 3:36 ` Li Yu
2012-06-15 8:35 ` David Laight
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=1339750318.7491.70.camel@edumazet-glaptop \
--to=eric.dumazet@gmail.com \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=raise.sail@gmail.com \
--cc=xiaosuo@gmail.com \
/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