From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Florian Westphal <fw@strlen.de>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>,
netdev@vger.kernel.org, Pablo Neira Ayuso <pablo@netfilter.org>,
Thomas Graf <tgraf@suug.ch>, Cong Wang <amwang@redhat.com>,
"Patrick McHardy" <kaber@trash.net>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Herbert Xu <herbert@gondor.hengli.com.au>
Subject: [net-next PATCH V2 1/9] net: frag evictor, avoid killing warm frag queues
Date: Thu, 29 Nov 2012 17:11:09 +0100 [thread overview]
Message-ID: <20121129161052.17754.85017.stgit@dragon> (raw)
In-Reply-To: <20121129161019.17754.29670.stgit@dragon>
The fragmentation evictor system have a very unfortunate eviction
system for killing fragment, when the system is put under pressure.
If packets are coming in too fast, the evictor code kills "warm"
fragments too quickly. Resulting in a massive performance drop,
because we drop frag lists where we have already queue up a lot of
fragments/work, which gets killed before they have a chance to
complete.
This is perhaps amplified by the CPUs fighting for the same lru_list
element q in inet_frag_evictor(), and the atomic_dec_and_test(&q->refcnt)
which will cause another trip round the loop.
The solution idea (orig conceived by Florian Westphal) is to avoid
killing "warm" fragments, and rather block new incoming in case mem
limit is exceeded. This is solved by introducing a creation time-stamp
(creation_ts) in inet_frag_queue, which set to "jiffies" in
inet_frag_alloc().
In inet_frag_evictor() we don't kill "warm" queue elements. A "warm"
queue element is an element reaching inet_frag_evictor() within the
same "jiffie".
To maintain the queue limit (/proc/sys/net/ipv4/ipfrag_high_thresh) we
don't allow, new frag queue's to be allocated in inet_frag_alloc().
This will result in kernel log messages, which have been adjusted to
"ip_frag_create: mem limit reached". We should consider dropping this
text, to avoid confusing end-users.
Notice, this is not the complete solution to fixing fragmentation
performance, but it allow us to see what is going on.
Original-idea-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Jesper Dangaard Brouer <jbrouer@redhat.com>
---
V2:
- Drop the INET_FRAG_FIRST_IN idea for detecting dropped "head" packets
include/net/inet_frag.h | 1 +
net/ipv4/inet_fragment.c | 19 +++++++++++++++++++
net/ipv4/ip_fragment.c | 6 +++---
3 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/include/net/inet_frag.h b/include/net/inet_frag.h
index 32786a0..7b897b2 100644
--- a/include/net/inet_frag.h
+++ b/include/net/inet_frag.h
@@ -24,6 +24,7 @@ struct inet_frag_queue {
ktime_t stamp;
int len; /* total length of orig datagram */
int meat;
+ u32 creation_ts;/* jiffies when queue was created*/
__u8 last_in; /* first/last segment arrived? */
#define INET_FRAG_COMPLETE 4
diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
index 4750d2b..9bb6237 100644
--- a/net/ipv4/inet_fragment.c
+++ b/net/ipv4/inet_fragment.c
@@ -178,6 +178,18 @@ int inet_frag_evictor(struct netns_frags *nf, struct inet_frags *f, bool force)
q = list_first_entry(&nf->lru_list,
struct inet_frag_queue, lru_list);
+
+ /* queue entry is warm, i.e. new frags are arriving
+ * too fast. instead of evicting warm entry, give it
+ * a chance to complete. Instead, inet_frag_alloc()
+ * will fail until more time has elapsed or queue
+ * completes.
+ */
+ if (!force && q->creation_ts == (u32) jiffies) {
+ read_unlock(&f->lock);
+ break;
+ }
+
atomic_inc(&q->refcnt);
read_unlock(&f->lock);
@@ -244,10 +256,17 @@ static struct inet_frag_queue *inet_frag_alloc(struct netns_frags *nf,
{
struct inet_frag_queue *q;
+ /* Guard creations of new frag queues if mem limit reached, as
+ * we allow warm/recent elements to survive in inet_frag_evictor()
+ */
+ if (atomic_read(&nf->mem) > nf->high_thresh)
+ return NULL;
+
q = kzalloc(f->qsize, GFP_ATOMIC);
if (q == NULL)
return NULL;
+ q->creation_ts = (u32) jiffies;
q->net = nf;
f->constructor(q, arg);
atomic_add(f->qsize, &nf->mem);
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 1cf6a76..ef00d0a 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -300,12 +300,12 @@ static inline struct ipq *ip_find(struct net *net, struct iphdr *iph, u32 user)
q = inet_frag_find(&net->ipv4.frags, &ip4_frags, &arg, hash);
if (q == NULL)
- goto out_nomem;
+ goto out_memlimit;
return container_of(q, struct ipq, q);
-out_nomem:
- LIMIT_NETDEBUG(KERN_ERR pr_fmt("ip_frag_create: no memory left !\n"));
+out_memlimit:
+ LIMIT_NETDEBUG(KERN_ERR pr_fmt("ip_frag_create: mem limit reached!\n"));
return NULL;
}
next prev parent reply other threads:[~2012-11-29 16:12 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-29 16:10 [net-next PATCH V2 0/9] net: fragmentation performance scalability on NUMA/SMP systems Jesper Dangaard Brouer
2012-11-29 16:11 ` Jesper Dangaard Brouer [this message]
2012-11-29 17:44 ` [net-next PATCH V2 1/9] net: frag evictor, avoid killing warm frag queues David Miller
2012-11-29 22:17 ` Jesper Dangaard Brouer
2012-11-29 23:01 ` Eric Dumazet
2012-11-30 10:04 ` Jesper Dangaard Brouer
2012-11-30 14:52 ` Eric Dumazet
2012-11-30 15:45 ` Jesper Dangaard Brouer
2012-11-30 16:37 ` Eric Dumazet
2012-11-30 21:37 ` Jesper Dangaard Brouer
2012-11-30 22:25 ` Eric Dumazet
2012-11-30 23:23 ` Jesper Dangaard Brouer
2012-11-30 23:47 ` Stephen Hemminger
2012-12-01 0:03 ` Eric Dumazet
2012-12-01 0:13 ` Stephen Hemminger
2012-11-30 23:58 ` Eric Dumazet
2012-12-04 13:30 ` [net-next PATCH V3-evictor] " Jesper Dangaard Brouer
2012-12-04 14:32 ` [net-next PATCH V3-evictor] net: frag evictor,avoid " David Laight
2012-12-04 14:47 ` [net-next PATCH V3-evictor] net: frag evictor, avoid " Eric Dumazet
2012-12-04 17:51 ` Jesper Dangaard Brouer
2012-12-05 9:24 ` Jesper Dangaard Brouer
2012-12-06 12:26 ` Jesper Dangaard Brouer
2012-12-06 12:32 ` Florian Westphal
2012-12-06 13:29 ` David Laight
2012-12-06 21:38 ` David Miller
2012-12-06 13:55 ` Jesper Dangaard Brouer
2012-12-06 14:47 ` Eric Dumazet
2012-12-06 15:23 ` Jesper Dangaard Brouer
2012-11-29 23:32 ` [net-next PATCH V2 1/9] " Eric Dumazet
2012-11-30 12:01 ` Jesper Dangaard Brouer
2012-11-30 14:57 ` Eric Dumazet
2012-11-29 16:11 ` [net-next PATCH V2 2/9] net: frag cache line adjust inet_frag_queue.net Jesper Dangaard Brouer
2012-11-29 16:12 ` [net-next PATCH V2 3/9] net: frag, move LRU list maintenance outside of rwlock Jesper Dangaard Brouer
2012-11-29 17:43 ` Eric Dumazet
2012-11-29 17:48 ` David Miller
2012-11-29 17:54 ` Eric Dumazet
2012-11-29 18:05 ` David Miller
2012-11-29 18:24 ` Eric Dumazet
2012-11-29 18:31 ` David Miller
2012-11-29 18:33 ` Eric Dumazet
2012-11-29 18:36 ` David Miller
2012-11-29 22:33 ` Jesper Dangaard Brouer
2012-11-29 16:12 ` [net-next PATCH V2 4/9] net: frag helper functions for mem limit tracking Jesper Dangaard Brouer
2012-11-29 16:13 ` [net-next PATCH V2 5/9] net: frag, per CPU resource, mem limit and LRU list accounting Jesper Dangaard Brouer
2012-11-29 17:06 ` Eric Dumazet
2012-11-29 17:31 ` David Miller
2012-12-03 14:02 ` Jesper Dangaard Brouer
2012-12-03 17:25 ` David Miller
2012-11-29 16:14 ` [net-next PATCH V2 6/9] net: frag, implement dynamic percpu alloc of frag_cpu_limit Jesper Dangaard Brouer
2012-11-29 16:15 ` [net-next PATCH V2 7/9] net: frag, move nqueues counter under LRU lock protection Jesper Dangaard Brouer
2012-11-29 16:15 ` [net-next PATCH V2 8/9] net: frag queue locking per hash bucket Jesper Dangaard Brouer
2012-11-29 17:08 ` Eric Dumazet
2012-11-30 12:55 ` Jesper Dangaard Brouer
2012-11-29 16:16 ` [net-next PATCH V2 9/9] net: increase frag queue hash size and cache-line Jesper Dangaard Brouer
2012-11-29 16:39 ` [net-next PATCH V2 9/9] net: increase frag queue hash size andcache-line David Laight
2012-11-29 16:55 ` [net-next PATCH V2 9/9] net: increase frag queue hash size and cache-line Eric Dumazet
2012-11-29 20:53 ` Jesper Dangaard Brouer
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=20121129161052.17754.85017.stgit@dragon \
--to=brouer@redhat.com \
--cc=amwang@redhat.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=fw@strlen.de \
--cc=herbert@gondor.hengli.com.au \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tgraf@suug.ch \
/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).