From: Grygorii Strashko <grygorii.strashko@ti.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Alan Stern <stern@rowland.harvard.edu>,
Thomas Gleixner <tglx@linutronix.de>
Cc: Lina Iyer <lina.iyer@linaro.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Mark Rutland <mark.rutland@arm.com>,
ulf.hansson@linaro.org,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
linux-pm@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
k.kozlowski@samsung.com, msivasub@codeaurora.org,
khilman@linaro.org, geert@linux-m68k.org, agross@codeaurora.org,
sboyd@codeaurora.org, linux-arm-kernel@lists.infradead.org,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH v2 7/7] ARM: smp: Add runtime PM support for CPU hotplug
Date: Mon, 7 Sep 2015 16:37:44 +0300 [thread overview]
Message-ID: <55ED9328.2010501@ti.com> (raw)
In-Reply-To: <2657565.lxWtPmdjyp@vostro.rjw.lan>
On 09/07/2015 04:04 PM, Rafael J. Wysocki wrote:
> On Saturday, September 05, 2015 11:39:20 AM Alan Stern wrote:
>> On Sat, 5 Sep 2015, Grygorii Strashko wrote:
>>
>>> On 09/04/2015 09:45 PM, Alan Stern wrote:
>>>> On Fri, 4 Sep 2015, Grygorii Strashko wrote:
>>>>
>>>>> There is one "small" problem with such approach :(
>>>>>
>>>>> - It's incompatible with -RT kernel, because PM runtime can't be used
>>>>> in atomic context on -RT.
>>>>
>>>> Can you explain this more fully? Why can't runtime PM be used in
>>>> atomic context in the -rt kernels?
>>>>
>>>
>>> See:
>>> http://lwn.net/Articles/146861/
>>> https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#How_does_the_CONFIG_PREEMPT_RT_patch_work.3F
>>>
>>> spinlock_t
>>> Critical sections are preemptible. The _irq operations (e.g., spin_lock_irqsave())
>>> do -not- disable hardware interrupts. Priority inheritance is used to prevent priority
>>> inversion. An underlying rt_mutex is used to implement spinlock_t in PREEMPT_RT.
>>>
>>> As result, have to do things like:
>>> https://lkml.org/lkml/2015/8/18/161
>>> https://lkml.org/lkml/2015/8/18/162
>>>
>>> Sorry for brief reply - Friday/Sat night :)
>>
>> I see. Although we normally think of interrupt contexts as being
>> atomic, in an -rt kernel this isn't true any more because things like
>> spin_lock_irq don't actually disable interrupts.
>>
>> Therefore it would be correct to say that in -rt kernels, runtime PM
>> can be used in interrupt context (if the device is marked as irq-safe),
>> but not in atomic context. Right?
>
> Right.
>
> Whatever is suitable for interrupt context in the mainline, will be suitable
> for that in -rt kernels too.
Not exactly true :(, since spinlock is converted to [rt_] mutex.
Usually, this difference can't be seen because on -RT kernel all or
mostly all HW IRQ handlers will be forced to be threaded.
For the cases, where such automatic conversion is not working,
(like chained irq handlers or HW-handler+Threaded handler) the code
has to be carefully patched to work properly as for non-RT as for -RT.
Also, this triggers some -RT incompatibility issues, like with PM runtime or
CLK framework (http://www.spinics.net/lists/linux-rt-users/msg13653.html).
> However, what is suitable for the idle loop
> in the mainline, may not be suitable for that in -rt kernels.
>
> That's why raw_spin_lock/unlock() need to be used within the idle loop.
Indeed. CPU hotplug/CPUIdle is guarded by local_irq_disable()/local_irq_enable().
(example of CPU hotplug RT-issue http://www.spinics.net/lists/arm-kernel/msg438963.html).
I don't want to be the final authority here as my experience with -RT is short.
But, I want to point out on potential issues based on what I've already discovered
and tried to fix.
Thanks & regards,
-grygorii
WARNING: multiple messages have this Message-ID (diff)
From: grygorii.strashko@ti.com (Grygorii Strashko)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 7/7] ARM: smp: Add runtime PM support for CPU hotplug
Date: Mon, 7 Sep 2015 16:37:44 +0300 [thread overview]
Message-ID: <55ED9328.2010501@ti.com> (raw)
In-Reply-To: <2657565.lxWtPmdjyp@vostro.rjw.lan>
On 09/07/2015 04:04 PM, Rafael J. Wysocki wrote:
> On Saturday, September 05, 2015 11:39:20 AM Alan Stern wrote:
>> On Sat, 5 Sep 2015, Grygorii Strashko wrote:
>>
>>> On 09/04/2015 09:45 PM, Alan Stern wrote:
>>>> On Fri, 4 Sep 2015, Grygorii Strashko wrote:
>>>>
>>>>> There is one "small" problem with such approach :(
>>>>>
>>>>> - It's incompatible with -RT kernel, because PM runtime can't be used
>>>>> in atomic context on -RT.
>>>>
>>>> Can you explain this more fully? Why can't runtime PM be used in
>>>> atomic context in the -rt kernels?
>>>>
>>>
>>> See:
>>> http://lwn.net/Articles/146861/
>>> https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#How_does_the_CONFIG_PREEMPT_RT_patch_work.3F
>>>
>>> spinlock_t
>>> Critical sections are preemptible. The _irq operations (e.g., spin_lock_irqsave())
>>> do -not- disable hardware interrupts. Priority inheritance is used to prevent priority
>>> inversion. An underlying rt_mutex is used to implement spinlock_t in PREEMPT_RT.
>>>
>>> As result, have to do things like:
>>> https://lkml.org/lkml/2015/8/18/161
>>> https://lkml.org/lkml/2015/8/18/162
>>>
>>> Sorry for brief reply - Friday/Sat night :)
>>
>> I see. Although we normally think of interrupt contexts as being
>> atomic, in an -rt kernel this isn't true any more because things like
>> spin_lock_irq don't actually disable interrupts.
>>
>> Therefore it would be correct to say that in -rt kernels, runtime PM
>> can be used in interrupt context (if the device is marked as irq-safe),
>> but not in atomic context. Right?
>
> Right.
>
> Whatever is suitable for interrupt context in the mainline, will be suitable
> for that in -rt kernels too.
Not exactly true :(, since spinlock is converted to [rt_] mutex.
Usually, this difference can't be seen because on -RT kernel all or
mostly all HW IRQ handlers will be forced to be threaded.
For the cases, where such automatic conversion is not working,
(like chained irq handlers or HW-handler+Threaded handler) the code
has to be carefully patched to work properly as for non-RT as for -RT.
Also, this triggers some -RT incompatibility issues, like with PM runtime or
CLK framework (http://www.spinics.net/lists/linux-rt-users/msg13653.html).
> However, what is suitable for the idle loop
> in the mainline, may not be suitable for that in -rt kernels.
>
> That's why raw_spin_lock/unlock() need to be used within the idle loop.
Indeed. CPU hotplug/CPUIdle is guarded by local_irq_disable()/local_irq_enable().
(example of CPU hotplug RT-issue http://www.spinics.net/lists/arm-kernel/msg438963.html).
I don't want to be the final authority here as my experience with -RT is short.
But, I want to point out on potential issues based on what I've already discovered
and tried to fix.
Thanks & regards,
-grygorii
next prev parent reply other threads:[~2015-09-07 13:39 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-03 19:58 [PATCH v2 0/7] PM / Domains: Generic PM domains for CPUs/Clusters Lina Iyer
2015-09-03 19:58 ` Lina Iyer
2015-09-03 19:58 ` [PATCH v2 1/7] PM / Domains: Allocate memory outside domain locks Lina Iyer
2015-09-03 19:58 ` Lina Iyer
2015-09-03 19:58 ` [PATCH v2 2/7] PM / Domains: Support IRQ safe PM domains Lina Iyer
2015-09-03 19:58 ` Lina Iyer
2015-09-04 10:02 ` Ulf Hansson
2015-09-04 10:02 ` Ulf Hansson
2015-09-04 16:05 ` Lina Iyer
2015-09-04 16:05 ` Lina Iyer
2015-10-01 21:11 ` Geert Uytterhoeven
2015-10-01 21:11 ` Geert Uytterhoeven
2015-09-03 19:58 ` [PATCH v2 3/7] drivers: cpu: Define CPU devices as IRQ safe Lina Iyer
2015-09-03 19:58 ` Lina Iyer
2015-09-04 4:00 ` Stephen Boyd
2015-09-04 4:00 ` Stephen Boyd
2015-09-03 19:58 ` [PATCH v2 4/7] PM / Domains: Introduce PM domains for CPUs/clusters Lina Iyer
2015-09-03 19:58 ` Lina Iyer
2015-09-04 3:54 ` Stephen Boyd
2015-09-04 3:54 ` Stephen Boyd
2015-09-03 19:58 ` [PATCH v2 5/7] ARM: cpuidle: Add runtime PM support for CPU idle Lina Iyer
2015-09-03 19:58 ` Lina Iyer
2015-09-03 19:58 ` [PATCH v2 6/7] ARM64: smp: Add runtime PM support for CPU hotplug Lina Iyer
2015-09-03 19:58 ` Lina Iyer
2015-09-30 12:36 ` Geert Uytterhoeven
2015-09-30 12:36 ` Geert Uytterhoeven
2015-09-03 19:58 ` [PATCH v2 7/7] ARM: " Lina Iyer
2015-09-03 19:58 ` Lina Iyer
2015-09-04 3:59 ` Stephen Boyd
2015-09-04 3:59 ` Stephen Boyd
2015-09-04 15:13 ` Lina Iyer
2015-09-04 15:13 ` Lina Iyer
2015-09-04 7:39 ` Geert Uytterhoeven
2015-09-04 7:39 ` Geert Uytterhoeven
2015-09-04 9:17 ` Russell King - ARM Linux
2015-09-04 9:17 ` Russell King - ARM Linux
2015-09-04 9:27 ` Russell King - ARM Linux
2015-09-04 9:27 ` Russell King - ARM Linux
2015-09-04 15:12 ` Lina Iyer
2015-09-04 15:12 ` Lina Iyer
2015-09-04 16:23 ` Russell King - ARM Linux
2015-09-04 16:23 ` Russell King - ARM Linux
2015-09-04 17:02 ` Lina Iyer
2015-09-04 17:02 ` Lina Iyer
2015-09-04 17:46 ` Russell King - ARM Linux
2015-09-04 17:46 ` Russell King - ARM Linux
2015-09-04 17:57 ` Grygorii Strashko
2015-09-04 17:57 ` Grygorii Strashko
2015-09-04 18:45 ` Alan Stern
2015-09-04 18:45 ` Alan Stern
2015-09-04 21:46 ` Grygorii Strashko
2015-09-04 21:46 ` Grygorii Strashko
2015-09-05 15:39 ` Alan Stern
2015-09-05 15:39 ` Alan Stern
2015-09-07 13:04 ` Rafael J. Wysocki
2015-09-07 13:04 ` Rafael J. Wysocki
2015-09-07 13:37 ` Grygorii Strashko [this message]
2015-09-07 13:37 ` Grygorii Strashko
2015-09-07 20:42 ` Rafael J. Wysocki
2015-09-07 20:42 ` Rafael J. Wysocki
2015-09-08 8:21 ` Grygorii Strashko
2015-09-08 8:21 ` Grygorii Strashko
2015-09-08 22:03 ` Kevin Hilman
2015-09-08 22:03 ` Kevin Hilman
2015-09-10 11:01 ` Grygorii Strashko
2015-09-10 11:01 ` Grygorii Strashko
2015-09-22 17:32 ` Lina Iyer
2015-09-22 17:32 ` Lina Iyer
2015-09-22 20:53 ` Thomas Gleixner
2015-09-22 20:53 ` Thomas Gleixner
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=55ED9328.2010501@ti.com \
--to=grygorii.strashko@ti.com \
--cc=agross@codeaurora.org \
--cc=catalin.marinas@arm.com \
--cc=geert@linux-m68k.org \
--cc=k.kozlowski@samsung.com \
--cc=khilman@linaro.org \
--cc=lina.iyer@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=msivasub@codeaurora.org \
--cc=rjw@rjwysocki.net \
--cc=sboyd@codeaurora.org \
--cc=stern@rowland.harvard.edu \
--cc=tglx@linutronix.de \
--cc=ulf.hansson@linaro.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.