From: Rick Jones <rick.jones2@hpe.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Eric Dumazet <edumazet@google.com>,
"David S . Miller" <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
Tom Herbert <tom@herbertland.com>
Subject: Re: [RFC net-next 2/2] udp: No longer use SLAB_DESTROY_BY_RCU
Date: Mon, 28 Mar 2016 11:44:00 -0700 [thread overview]
Message-ID: <56F97B70.1000904@hpe.com> (raw)
In-Reply-To: <1459184434.6473.104.camel@edumazet-glaptop3.roam.corp.google.com>
On 03/28/2016 10:00 AM, Eric Dumazet wrote:
> On Mon, 2016-03-28 at 09:15 -0700, Rick Jones wrote:
>> On 03/25/2016 03:29 PM, Eric Dumazet wrote:
>>> UDP sockets are not short lived in the high usage case, so the added
>>> cost of call_rcu() should not be a concern.
>>
>> Even a busy DNS resolver?
>
> If you mean that a busy DNS resolver spends _most_ of its time doing :
>
> fd = socket()
> bind(fd port=0)
> < send and receive one frame >
> close(fd)
Yes. Although it has been a long time, I thought that say the likes of
a caching named in the middle between hosts and the rest of the DNS
would behave that way as it was looking-up names on behalf those who
asked it.
rick
>
> (If this is the case, may I suggest doing something different, and use
> some kind of caches ? It will be way faster.)
>
> Then the result for 10,000,000 loops of <socket()+bind()+close()> are
>
> Before patch :
>
> real 0m13.665s
> user 0m0.548s
> sys 0m12.372s
>
> After patch :
>
> real 0m20.599s
> user 0m0.465s
> sys 0m17.965s
>
> So the worst overhead is 700 ns
>
> This is roughly the cost for bringing 960 bytes from memory, or 15 cache
> lines (on x86_64)
>
> # grep UDP /proc/slabinfo
> UDPLITEv6 0 0 1088 7 2 : tunables 24 12 8 : slabdata 0 0 0
> UDPv6 24 49 1088 7 2 : tunables 24 12 8 : slabdata 7 7 0
> UDP-Lite 0 0 960 4 1 : tunables 54 27 8 : slabdata 0 0 0
> UDP 30 36 960 4 1 : tunables 54 27 8 : slabdata 9 9 2
>
> In reality, chances that UDP sockets are re-opened right after being
> freed and their 15 cache lines are very hot in cpu caches is quite
> small, so I would not worry at all about this rather stupid benchmark.
>
> int main(int argc, char *argv[]) {
> struct sockaddr_in addr;
> int i, fd, loops = 10000000;
>
> for (i = 0; i < loops; i++) {
> fd = socket(AF_INET, SOCK_DGRAM, 0);
> if (fd == -1) {
> perror("socket");
> break;
> }
> memset(&addr, 0, sizeof(addr));
> addr.sin_family = AF_INET;
> if (bind(fd, (const struct sockaddr *)&addr, sizeof(addr)) == -1) {
> perror("bind");
> break;
> }
> close(fd);
> }
> return 0;
> }
>
next prev parent reply other threads:[~2016-03-28 18:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-25 22:29 [RFC net-next 0/2] udp: use standard RCU rules Eric Dumazet
2016-03-25 22:29 ` [RFC net-next 1/2] net: add SOCK_RCU_FREE socket flag Eric Dumazet
2016-03-26 0:08 ` Tom Herbert
2016-03-25 22:29 ` [RFC net-next 2/2] udp: No longer use SLAB_DESTROY_BY_RCU Eric Dumazet
2016-03-26 0:08 ` Tom Herbert
2016-03-28 21:02 ` Eric Dumazet
2016-03-26 1:55 ` Alexei Starovoitov
2016-03-28 16:15 ` Rick Jones
2016-03-28 16:54 ` Tom Herbert
2016-03-28 17:00 ` Eric Dumazet
2016-03-28 18:44 ` Rick Jones [this message]
2016-03-28 18:55 ` Eric Dumazet
2016-03-28 19:11 ` Rick Jones
2016-03-28 20:01 ` Eric Dumazet
2016-03-28 20:15 ` Rick Jones
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=56F97B70.1000904@hpe.com \
--to=rick.jones2@hpe.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=tom@herbertland.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;
as well as URLs for NNTP newsgroup(s).