[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20130103124608.136fd65b.akpm@linux-foundation.org>
Date: Thu, 3 Jan 2013 12:46:08 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Tom Herbert <therbert@...gle.com>
Subject: Re: [PATCH net-next] softirq: reduce latencies
On Thu, 03 Jan 2013 04:28:52 -0800
Eric Dumazet <eric.dumazet@...il.com> wrote:
> From: Eric Dumazet <edumazet@...gle.com>
>
> In various network workloads, __do_softirq() latencies can be up
> to 20 ms if HZ=1000, and 200 ms if HZ=100.
>
> This is because we iterate 10 times in the softirq dispatcher,
> and some actions can consume a lot of cycles.
hm, where did that "20 ms" come from? What caused it? Is it simply
the case that you happened to have actions which consume 2ms if HZ=1000
and 20ms if HZ=100?
> This patch changes the fallback to ksoftirqd condition to :
>
> - A time limit of 2 ms.
> - need_resched() being set on current task
>
> When one of this condition is met, we wakeup ksoftirqd for further
> softirq processing if we still have pending softirqs.
Do we need both tests? The need_resched() test alone might be
sufficient?
With this change, there is a possibility that a rapidly-rescheduling
task will cause softirq starvation?
Can this change cause worsened latencies in some situations? Say there
are a large number of short-running actions queued. Presently we'll
dispatch ten of them and return. With this change we'll dispatch many
more of them - however many consume 2ms. So worst-case latency
increases from "10 * not-much" to "2 ms".
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists