From: Zlatko Calusic <zlatko.calusic@iskon.hr>
To: Tejun Heo <tj@kernel.org>
Cc: linux-kernel@vger.kernel.org
Subject: High context switch rate, ksoftirqd's chewing cpu
Date: Sat, 17 Nov 2012 14:01:29 +0100 [thread overview]
Message-ID: <50A78AA9.5040904@iskon.hr> (raw)
[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]
Hello Tejun et al.
This week I spent some hours tracking a regression in 3.7 kernel that
was producing high context switch rate on one of my machines. I
carefully bisected between 3.6 and 3.7-rc1 and eventually found this
commit a culprit:
commit e7c2f967445dd2041f0f8e3179cca22bb8bb7f79
Author: Tejun Heo <tj@kernel.org>
Date: Tue Aug 21 13:18:24 2012 -0700
workqueue: use mod_delayed_work() instead of __cancel + queue
Now that mod_delayed_work() is safe to call from IRQ handlers,
__cancel_delayed_work() followed by queue_delayed_work() can be
replaced with mod_delayed_work().
Most conversions are straight-forward except for the following.
* net/core/link_watch.c: linkwatch_schedule_work() was doing a quite
elaborate dancing around its delayed_work. Collapse it such that
linkwatch_work is queued for immediate execution if LW_URGENT and
existing timer is kept otherwise.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Then I carefully reverted chunk by chunk to find out what exact change
is responsible for the regression. You can find it attached as wq.patch
(to preserve whitespace). Very simple modification with wildly different
behavior on only one of my machines, weird. I'm also attaching ctxt/s
graph that shows the impact nicely. I'll gladly provide any additional
info that could help you resolve this.
Please Cc: on reply (not subscribed to lkml).
Regards,
--
Zlatko
[-- Attachment #2: wq.patch --]
[-- Type: text/x-patch, Size: 521 bytes --]
diff --git a/block/blk-core.c b/block/blk-core.c
index 4b4dbdf..4b8b606 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -319,10 +319,8 @@ EXPORT_SYMBOL(__blk_run_queue);
*/
void blk_run_queue_async(struct request_queue *q)
{
- if (likely(!blk_queue_stopped(q))) {
- __cancel_delayed_work(&q->delay_work);
- queue_delayed_work(kblockd_workqueue, &q->delay_work, 0);
- }
+ if (likely(!blk_queue_stopped(q)))
+ mod_delayed_work(kblockd_workqueue, &q->delay_work, 0);
}
EXPORT_SYMBOL(blk_run_queue_async);
[-- Attachment #3: context-weekly.png --]
[-- Type: image/png, Size: 11787 bytes --]
next reply other threads:[~2012-11-17 13:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-17 13:01 Zlatko Calusic [this message]
2012-11-30 22:52 ` High context switch rate, ksoftirqd's chewing cpu Tejun Heo
2012-11-30 22:55 ` Tejun Heo
2012-12-01 11:06 ` Zlatko Calusic
2012-12-01 14:38 ` Tejun Heo
2012-12-01 17:11 ` Zlatko Calusic
2012-12-01 19:13 ` Tejun Heo
2012-12-01 22:11 ` Zlatko Calusic
2012-11-30 23:11 ` Zlatko Calusic
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=50A78AA9.5040904@iskon.hr \
--to=zlatko.calusic@iskon.hr \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@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.