From: Thomas Renninger <trenn@suse.de>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>,
Andre Przywara <andre.przywara@amd.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, cpufreq@vger.kernel.org,
linux-pm@vger.kernel.org, Duncan <1i5t5.duncan@cox.net>,
Andreas Herrmann <andreas.herrmann3@amd.com>
Subject: Re: [PATCH 3.6-rc6] cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU
Date: Sun, 23 Sep 2012 03:53:48 +0200 [thread overview]
Message-ID: <201209230353.49737.trenn@suse.de> (raw)
In-Reply-To: <201209172238.21087.rjw@sisk.pl>
Hi,
better late than never..
On Monday 17 September 2012 22:38:20 Rafael J. Wysocki wrote:
> On Monday, September 17, 2012, Tejun Heo wrote:
> > powernowk8_target() runs off a per-cpu work item and if the
> > cpufreq_policy->cpu is different from the current one, it migrates the
> > kworker to the target CPU by manipulating current->cpus_allowed. The
> > function migrates the kworker back to the original CPU but this is
> > still broken. Workqueue concurrency management requires the kworkers
> > to stay on the same CPU and powernowk8_target() ends up triggerring
> > BUG_ON(rq != this_rq()) in try_to_wake_up_local() if it contends on
> > fidvid_mutex and sleeps.
> >
> > It is unclear why this bug is being reported now. Duncan says it
> > appeared to be a regression of 3.6-rc1 and couldn't reproduce it on
> > 3.5. Bisection seemed to point to 63d95a91 "workqueue: use @pool
> > instead of @gcwq or @cpu where applicable" which is an non-functional
> > change. Given that the reproduce case sometimes took upto days to
> > trigger, it's easy to be misled while bisecting. Maybe something made
> > contention on fidvid_mutex more likely? I don't know.
> >
> > This patch fixes the bug by punting to another per-cpu work item on
> > the target CPU if it isn't the same as the current one. The code
> > assumes that cpufreq_policy->cpu is kept online by the caller, which
> > Rafael tells me is the case.
> >
> > Signed-off-by: Tejun Heo <tj@kernel.org>
> > Reported-by: Duncan <1i5t5.duncan@cox.net>
> > Cc: Rafael J. Wysocki <rjw@sisk.pl>
> > Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
> > Cc: stable@kernel.org
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47301
> > ---
> >
> > While it's very late in the merge cycle, the fix is limited in scope
> > and fairly safe, so it wouldn't be too crazy to merge but then again
> > this can go through the next -rc1 and then -stable. Linus, Rafael,
> > what do you guys think?
>
> Well, I don't see much reason to wait with this, although I'd like some
> more people to check it.
>
> Andre, Thomas, can you please have a look at it?
The cpufreq changes are not really (functional) changes.
I cannot judge the risk of the real change:
> > + INIT_WORK_ONSTACK(&tw.work, powernowk8_target_on_cpu);
instead of using set_cpus_allowed_ptr.
Changing scheduler behavior of powernow-k8
sounds rather intrusive for rc6, but I would fully trust
Tejun's advise on this.
I wonder whether more drivers are affected similarly, grepping for:
set_cpus_allowed_ptr
shows quite some hits.
My 2 cents...,
Thomas
next prev parent reply other threads:[~2012-09-23 1:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-17 20:17 [PATCH 3.6-rc6] cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU Tejun Heo
2012-09-17 20:36 ` Borislav Petkov
2012-09-17 20:53 ` Tejun Heo
2012-09-17 21:22 ` Borislav Petkov
2012-09-17 20:38 ` Rafael J. Wysocki
2012-09-23 1:53 ` Thomas Renninger [this message]
2012-09-18 20:12 ` Tejun Heo
2012-09-18 20:27 ` Linus Torvalds
2012-09-18 20:49 ` [PATCH 3.6-rc6 1/2] workqueue: reimplement work_on_cpu() using system_wq Tejun Heo
2012-09-18 20:51 ` [PATCH 3.6-rc6 2/2] cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU Tejun Heo
2012-09-18 20:30 ` [PATCH 3.6-rc6] " Rafael J. Wysocki
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=201209230353.49737.trenn@suse.de \
--to=trenn@suse.de \
--cc=1i5t5.duncan@cox.net \
--cc=andre.przywara@amd.com \
--cc=andreas.herrmann3@amd.com \
--cc=cpufreq@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.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 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).