[RFC/PATCH 5/7] ARM: Move get_thread_info macro definition to <asm/assembler.h>

[George G. Davis]

On Oct 13, 2011, at 10:53 AM, Russell King - ARM Linux wrote:

> On Thu, Oct 13, 2011 at 03:49:23PM +0100, Catalin Marinas wrote:
>> On Thu, Oct 13, 2011 at 03:34:20PM +0100, Russell King - ARM Linux wrote:
>>> On Wed, Oct 12, 2011 at 02:04:33AM -0400, gdavis at mvista.com wrote:
>>>> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
>>>> index 78397d0..eaf4939 100644
>>>> --- a/arch/arm/include/asm/assembler.h
>>>> +++ b/arch/arm/include/asm/assembler.h
>>>> @@ -36,6 +36,20 @@
>>>> 	.endm
>>>> #endif  /* !CONFIG_THUMB2_KERNEL */
>>>> 
>>>> +	.macro	preempt_disable, tsk, cnt
>>>> +	get_thread_info \tsk
>>>> +	ldr	\cnt, [\tsk, #TI_PREEMPT]
>>>> +	add	\cnt, \cnt, #1
>>>> +	str	\cnt, [\tsk, #TI_PREEMPT]
>>>> +	.endm
>>>> +
>>>> +	.macro	preempt_enable, tsk, cnt
>>>> +	get_thread_info \tsk
>>>> +	ldr	\cnt, [\tsk, #TI_PREEMPT]
>>>> +	sub	\cnt, \cnt, #1
>>>> +	str	\cnt, [\tsk, #TI_PREEMPT]
>>>> +	.endm
>>>> +
>>>> /*
>>>>  * Endian independent macros for shifting bytes within registers.
>>>>  */
>>>> 
>>>> 
>>>> Not as efficient as it could be but I imagine the macros could
>>>> be written to support optional load of \tsk and/or optional \tmp
>>>> parameters to cover other common cases.
>>> 
>>> It's actually not that simple either: if you disable preemption, then you
>>> need to check for a preempt event after re-enabling preemption.
>> 
>> That's not easily possible in assembly as calling a function would
>> corrupt some registers. Is there any disadvantage with just doing the
>> equivalent of preempt_enable_no_resched() for a few asm cases where this
>> is needed?
> 
> It means you drop preemption reschedule events, which means that you can
> no longer do hard-RT in any shape or form (because you're dropping the
> reschedule for an indefinite amount of time.)

I ignored that due to laziness in this series.  I figured it was a small window
and another interrupt will come along soon enough but yes, it does impact
preempt latency.

> preempt_enable_no_resched() is fine if you're going to also put an
> explicit check a bit later in the code path when it is convenient to
> do so.

I implemented it for all cases here and will submit an update.

Thanks!

--
Regards,
George