From: Vitaly Mayatskikh <v.mayatskih@gmail.com>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: speed regression in udp_lib_lport_inuse()
Date: Thu, 22 Jan 2009 19:49:30 +0100 [thread overview]
Message-ID: <m3sknbuqf9.wl%vmayatsk@redhat.com> (raw)
Hello!
I found your latest patches w.r.t. udp port randomization really solve
the "finding shortest chain kills randomness" problem, but
significantly slow down system in the case when almost every port is
in use. Kernel spends too much time trying to find free port number.
Try to compile and run this reproducer (after increasing open files
limit).
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <pthread.h>
#include <assert.h>
#define PORTS 65536
#define NP 64
#define THREADS
void* foo(void* arg)
{
int s, err, i, j;
struct sockaddr_in sa;
int optval = 1, port;
unsigned int p[PORTS] = { 0 };
for (i = 0; i < PORTS * 100; ++i) {
s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
assert(s > 0);
memset(&sa, 0, sizeof(sa));
sa.sin_addr.s_addr = htonl(INADDR_ANY);
sa.sin_family = AF_INET;
sa.sin_port = 0;
err = bind(s, (const struct sockaddr*)&sa, sizeof(sa));
getsockname(s, (struct sockaddr*)&sa, &j);
port = ntohs(sa.sin_port);
p[port] = s;
// free some ports
if (p[port + 1]) {
close(p[port + 1]);
p[port + 1] = 0;
}
if (p[port - 1]) {
close(p[port - 1]);
p[port - 1] = 0;
}
}
}
int main()
{
int i, err;
#ifdef THREADS
pthread_t t[NP];
for (i = 0; i < NP; ++i)
{
err = pthread_create(&t[i], NULL, foo, NULL);
assert(err == 0);
}
for (i = 0; i < NP; ++i)
{
err = pthread_join(t[i], NULL);
assert(err == 0);
}
#else
for (i = 0; i < NP; ++i) {
err = fork();
if (err == 0)
foo(NULL);
}
#endif
}
I ran glxgears and had these numbers:
$ glxgears
3297 frames in 5.0 seconds = 659.283 FPS
3680 frames in 5.0 seconds = 735.847 FPS
3840 frames in 5.0 seconds = 767.891 FPS
3574 frames in 5.0 seconds = 714.704 FPS
-> here I ran reproducer
2507 frames in 5.1 seconds = 493.173 FPS
56 frames in 7.7 seconds = 7.316 FPS
14 frames in 5.1 seconds = 2.752 FPS
1 frames in 6.8 seconds = 0.146 FPS
9 frames in 7.6 seconds = 1.188 FPS
1 frames in 9.3 seconds = 0.108 FPS
12 frames in 5.5 seconds = 2.187 FPS
30 frames in 9.0 seconds = 3.338 FPS
25 frames in 5.1 seconds = 4.888 FPS
<- here I killed reproducer
1034 frames in 5.0 seconds = 206.764 FPS
3728 frames in 5.0 seconds = 745.541 FPS
3668 frames in 5.0 seconds = 733.496 FPS
Last stable kernel survives it more or less smoothly.
Thanks!
--
wbr, Vitaly
next reply other threads:[~2009-01-22 18:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-22 18:49 Vitaly Mayatskikh [this message]
2009-01-22 22:06 ` speed regression in udp_lib_lport_inuse() Eric Dumazet
2009-01-22 22:14 ` Evgeniy Polyakov
2009-01-23 0:20 ` Eric Dumazet
2009-01-22 22:40 ` Vitaly Mayatskikh
2009-01-23 0:14 ` Eric Dumazet
2009-01-23 9:42 ` Vitaly Mayatskikh
2009-01-23 11:45 ` Eric Dumazet
2009-01-23 13:44 ` Eric Dumazet
2009-01-23 14:56 ` Vitaly Mayatskikh
2009-01-23 16:05 ` Eric Dumazet
2009-01-23 16:14 ` Vitaly Mayatskikh
2009-01-26 8:20 ` [PATCH] udp: optimize bind(0) if many ports are in use Eric Dumazet
2009-01-27 5:35 ` David Miller
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=m3sknbuqf9.wl%vmayatsk@redhat.com \
--to=v.mayatskih@gmail.com \
--cc=dada1@cosmosbay.com \
--cc=davem@davemloft.net \
--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).