From: Eric Dumazet <erdnetdev@gmail.com>
To: "Oleg A.Arkhangelsky" <sysoleg@yandex.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Miller <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Tom Herbert <therbert@google.com>
Subject: Re: [PATCH net-next] softirq: reduce latencies
Date: Thu, 03 Jan 2013 23:46:37 -0800 [thread overview]
Message-ID: <1357285597.21409.28406.camel@edumazet-glaptop> (raw)
In-Reply-To: <787701357283699@web24e.yandex.ru>
On Fri, 2013-01-04 at 11:14 +0400, Oleg A.Arkhangelsky wrote:
> It leads to many context switches when softirqs processing deffered to
> ksoftirqd kthreads which can be very expensive. Here is some evidence
> of ksoftirqd activation effects:
>
> http://marc.info/?l=linux-netdev&m=124116262916969&w=2
>
> Look for "magic threshold". Yes, I know there was another bug in scheduler
> discovered that time, but this bug was only about tick accounting.
>
This thread is 3 years old :
- It was a router workload. Forwarded packets should not wakeup a task.
- The measure of how cpus spent their cycles was completely wrong.
- A lot of things have changed, both in network stack and scheduler.
In fact, under moderate load, my patch is able to loop more than 10
times before deferring to ksoftirqd.
Under stress, ksoftirqd will be started anyway, and its a good thing,
because it enables process migration.
500 "context switches" [1] per second instead of 50 on behalf of
ksoftirqd is absolutely not measurable. It also permits smoother RCU
cleanups.
I did a lot of benchmarks, and didnt see any regression yet, but usual
noise.
[1] Under load, __do_softirq() would be called 500 times per second,
instead of ~50 times per second.
next prev parent reply other threads:[~2013-01-04 7:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-03 12:28 [PATCH net-next] softirq: reduce latencies Eric Dumazet
2013-01-03 20:46 ` Andrew Morton
2013-01-03 22:41 ` Eric Dumazet
2013-01-04 5:16 ` Namhyung Kim
2013-01-04 6:53 ` Eric Dumazet
[not found] ` <787701357283699@web24e.yandex.ru>
2013-01-04 7:46 ` Eric Dumazet [this message]
2013-01-03 22:08 ` Ben Hutchings
2013-01-03 22:40 ` Eric Dumazet
2013-01-04 7:49 ` [PATCH v2 " Eric Dumazet
2013-01-04 8:15 ` Joe Perches
2013-01-04 8:23 ` Eric Dumazet
2013-01-04 9:12 ` Joe Perches
2013-01-04 17:00 ` Eric Dumazet
2013-01-04 21:15 ` [PATCH] jiffies conversions: Use compile time constants when possible Joe Perches
2013-01-04 21:49 ` [PATCH v2 net-next] softirq: reduce latencies David Miller
-- strict thread matches above, loose matches on Subject: below --
2013-01-03 13:12 [PATCH " Sedat Dilek
2013-01-03 13:31 ` Eric Dumazet
2013-01-03 19:41 ` Rick Jones
2013-01-04 4:41 ` Eric Dumazet
2013-01-04 5:31 ` Sedat Dilek
2013-01-04 6:54 ` Eric Dumazet
2013-01-04 11:57 ` Sedat Dilek
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=1357285597.21409.28406.camel@edumazet-glaptop \
--to=erdnetdev@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sysoleg@yandex.ru \
--cc=therbert@google.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