Hi,
today we have the possibility to mask the local interrupt with the
command local_irq_disable / local_irq_enable.
The power management path disables the local interrupt in order to
initiate a power down sequence. If there is a pending interrupt this one
will make the power down function to abort, thus exiting right after
calling the shutdown function after costly operations. It could be
interesting to check if there is a pending interrupt before initiating
the power down sequence.
Is there a way to know if there is a pending interrupt on the current
CPU when the local interrupt are disabled? Something like,
local_irq_pending() function ?
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
On Thu, 14 Feb 2019, Daniel Lezcano wrote:
> today we have the possibility to mask the local interrupt with the
> command local_irq_disable / local_irq_enable.
>
> The power management path disables the local interrupt in order to
> initiate a power down sequence. If there is a pending interrupt this one
> will make the power down function to abort, thus exiting right after
> calling the shutdown function after costly operations. It could be
> interesting to check if there is a pending interrupt before initiating
> the power down sequence.
>
> Is there a way to know if there is a pending interrupt on the current
> CPU when the local interrupt are disabled? Something like,
> local_irq_pending() function ?
We have nothing like that today, but it would be possible to implement this
at least on x86 by peeking the local APIC registers.
OTOH, the question is whether it's worth the trouble because the interrupt
could come in right after the query and the same issue which you want to
address persists. It only makes sense if it reduces the time window so
significantly that it actually matters.
Thanks,
tglx
On 14/02/2019 15:35, Thomas Gleixner wrote:
> On Thu, 14 Feb 2019, Daniel Lezcano wrote:
>> today we have the possibility to mask the local interrupt with the
>> command local_irq_disable / local_irq_enable.
>>
>> The power management path disables the local interrupt in order to
>> initiate a power down sequence. If there is a pending interrupt this one
>> will make the power down function to abort, thus exiting right after
>> calling the shutdown function after costly operations. It could be
>> interesting to check if there is a pending interrupt before initiating
>> the power down sequence.
>>
>> Is there a way to know if there is a pending interrupt on the current
>> CPU when the local interrupt are disabled? Something like,
>> local_irq_pending() function ?
>
> We have nothing like that today, but it would be possible to implement this
> at least on x86 by peeking the local APIC registers.
On arm64, reading ISR_EL1 would give some indication of that, but...
> OTOH, the question is whether it's worth the trouble because the interrupt
> could come in right after the query and the same issue which you want to
> address persists. It only makes sense if it reduces the time window so
> significantly that it actually matters.
as Thomas explains, the potential race is pretty tight.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Hi Thomas,
On 14/02/2019 16:35, Thomas Gleixner wrote:
> On Thu, 14 Feb 2019, Daniel Lezcano wrote:
>> today we have the possibility to mask the local interrupt with the
>> command local_irq_disable / local_irq_enable.
>>
>> The power management path disables the local interrupt in order to
>> initiate a power down sequence. If there is a pending interrupt this one
>> will make the power down function to abort, thus exiting right after
>> calling the shutdown function after costly operations. It could be
>> interesting to check if there is a pending interrupt before initiating
>> the power down sequence.
>>
>> Is there a way to know if there is a pending interrupt on the current
>> CPU when the local interrupt are disabled? Something like,
>> local_irq_pending() function ?
>
> We have nothing like that today, but it would be possible to implement this
> at least on x86 by peeking the local APIC registers.
>
> OTOH, the question is whether it's worth the trouble because the interrupt
> could come in right after the query and the same issue which you want to
> address persists. It only makes sense if it reduces the time window so
> significantly that it actually matters.
Yes, I agree. It should be worth only if we can prove we enter the deep
idle sequence with pending interrupts much more often than what we expect.
Actually, we have a similar action when the need_resched() is true, we
abort the idle sequence and exit the loop.
--
<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
Hi Thomas,
thanks for the answer,
On 14/02/2019 16:47, Marc Zyngier wrote:
> On 14/02/2019 15:35, Thomas Gleixner wrote:
>> On Thu, 14 Feb 2019, Daniel Lezcano wrote:
>>> today we have the possibility to mask the local interrupt with the
>>> command local_irq_disable / local_irq_enable.
>>>
>>> The power management path disables the local interrupt in order to
>>> initiate a power down sequence. If there is a pending interrupt this one
>>> will make the power down function to abort, thus exiting right after
>>> calling the shutdown function after costly operations. It could be
>>> interesting to check if there is a pending interrupt before initiating
>>> the power down sequence.
>>>
>>> Is there a way to know if there is a pending interrupt on the current
>>> CPU when the local interrupt are disabled? Something like,
>>> local_irq_pending() function ?
>>
>> We have nothing like that today, but it would be possible to implement this
>> at least on x86 by peeking the local APIC registers.
>
> On arm64, reading ISR_EL1 would give some indication of that, but...
Does 'some indication' means as soon as we read the ISR_EL1 it may be
outdated right after ?
>> OTOH, the question is whether it's worth the trouble because the interrupt
>> could come in right after the query and the same issue which you want to
>> address persists. It only makes sense if it reduces the time window so
>> significantly that it actually matters.
>
> as Thomas explains, the potential race is pretty tight.
Is a simple hack possible on ARM64 to check if it is worth or not?
--
<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