From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Michal Kubecek <mkubecek@suse.cz>
Cc: liujian56@huawei.com, netdev@vger.kernel.org,
Florian Westphal <fw@strlen.de>,
brouer@redhat.com
Subject: Re: [RFC PATCH] net: frag limit checks need to use percpu_counter_compare
Date: Fri, 1 Sep 2017 09:41:56 +0200 [thread overview]
Message-ID: <20170901094156.12e6e0a3@redhat.com> (raw)
In-Reply-To: <20170831162349.k3qnkfgkygdh2zqw@unicorn.suse.cz>
On Thu, 31 Aug 2017 18:23:49 +0200 Michal Kubecek <mkubecek@suse.cz> wrote:
> If we go this way (which would IMHO require some benchmarks to make sure
> it doesn't harm performance too much) we can drop the explicit checks
> for zero thresholds which were added to work around the unreliability of
> fast checks of percpu counters (or at least the second one was by commit
> 30759219f562 ("net: disable fragment reassembly if high_thresh is zero").
After much considerations, together with Florian, I'm now instead
looking at reverting the use of percpu_counter for this memory
accounting use-case. The complexity and maintenance cost is not worth
it. And I'm of-cause testing the perf effect, and currently I'm _not_
seeing any perf regression on my 10G + 100G testlab (although this is
not a NUMA system, which were my original optimization case).
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2017-09-01 7:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-31 10:20 [RFC PATCH] net: frag limit checks need to use percpu_counter_compare Jesper Dangaard Brouer
2017-08-31 15:58 ` Stephen Hemminger
2017-08-31 16:23 ` Michal Kubecek
2017-09-01 2:25 ` liujian (CE)
2017-09-01 7:16 ` Jesper Dangaard Brouer
2017-09-01 7:41 ` Jesper Dangaard Brouer [this message]
2017-09-01 8:10 ` Michal Kubecek
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=20170901094156.12e6e0a3@redhat.com \
--to=brouer@redhat.com \
--cc=fw@strlen.de \
--cc=liujian56@huawei.com \
--cc=mkubecek@suse.cz \
--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 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.