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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.