From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: rafael.j.wysocki@intel.com
Cc: Russ Anderson <rja@sgi.com>,
linux-pm@vger.kernel.org, pdeschrijver@nvidia.com,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
rja@americas.sgi.com
Subject: Re: [PATCH] cpuidle - fix lock contention in the idle path
Date: Fri, 04 Jan 2013 07:27:24 +0100 [thread overview]
Message-ID: <50E6764C.9060608@linaro.org> (raw)
In-Reply-To: <20130102211314.GA29447@sgi.com>
On 01/02/2013 10:13 PM, Russ Anderson wrote:
> On Wed, Dec 26, 2012 at 11:01:48AM +0100, Daniel Lezcano wrote:
>> The commit bf4d1b5ddb78f86078ac6ae0415802d5f0c68f92 introduces
>> a lock in the cpuidle_get_cpu_driver function. This function
>> is used in the idle_call function.
>>
>> The problem is the contention with a large number of cpus because
>> they try to access the idle routine at the same time.
>>
>> The lock could be safely removed because of how is used the
>> cpuidle api. The cpuidle_register_driver is called first but
>> until the cpuidle_register_device is not called we don't
>> enter in the cpuidle idle call function because the device
>> is not enabled.
>>
>> The cpuidle_unregister_driver function, leading the a NULL driver,
>> is not called before the cpuidle_unregister_device.
>>
>> This is how is used the cpuidle api from the different drivers.
>>
>> However, a cleanup around the lock and a proper refcounting
>> mechanism should be used to ensure the consistency in the api,
>> like cpuidle_unregister_driver should failed if its refcounting
>> is not 0.
>>
>> These modifications will need some code reorganization and rewrite
>> which does not fit with a fix.
>
> I agree.
>
>> The following patch is a hot fix by returning to the initial behavior
>> by removing the lock when getting the driver.
>
> The patch fixes the problem. Verified on a system with 1024 cpus.
> Thanks.
>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>
> Reported-by: Russ Anderson <rja@sgi.com>
> Acked-by: Russ Anderson <rja@sgi.com>
Hi Rafael,
could you consider this patch for merging ?
Thanks
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
next prev parent reply other threads:[~2013-01-04 6:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-26 10:01 [PATCH] cpuidle - fix lock contention in the idle path Daniel Lezcano
2012-12-29 10:03 ` Daniel Lezcano
2012-12-31 15:08 ` Russ Anderson
2013-01-02 21:13 ` Russ Anderson
2013-01-04 6:27 ` Daniel Lezcano [this message]
2013-01-05 0:03 ` Rafael J. Wysocki
2013-01-06 23:07 ` Daniel Lezcano
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=50E6764C.9060608@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pdeschrijver@nvidia.com \
--cc=rafael.j.wysocki@intel.com \
--cc=rja@americas.sgi.com \
--cc=rja@sgi.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 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.