Moving inband work off stack - remaing cases

Moving inband work off stack - remaing cases

[Jan Kiszka]

Hi Philippe,

I'm trying to understand the reasoning for moving inband work struct for
the remaining cases of the triggering stack.

To my understanding, this is not needed for xnthread_map (to be
privatized soon, so only for the in-tree case) because the caller
providing the struct waits for the completion which will be triggered
via the inband handler.

Looking at xnthread_relax(), the same should apply to post_wakeup -
provided it is inlined into xnthread_relax - because, again, we won't
leave that function before the signal was sent, thus the work consumed.

Am I missing something?

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: Moving inband work off stack - remaing cases

[Philippe Gerum]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> Hi Philippe,
>
> I'm trying to understand the reasoning for moving inband work struct for
> the remaining cases of the triggering stack.
>
> To my understanding, this is not needed for xnthread_map (to be
> privatized soon, so only for the in-tree case) because the caller
> providing the struct waits for the completion which will be triggered
> via the inband handler.
>

Correct.

> Looking at xnthread_relax(), the same should apply to post_wakeup -
> provided it is inlined into xnthread_relax - because, again, we won't
> leave that function before the signal was sent, thus the work consumed.
>

Correct.

> Am I missing something?
>

Nope.

-- 
Philippe.

Re: Moving inband work off stack - remaing cases

[Jan Kiszka]

On 11.06.21 17:35, Philippe Gerum wrote:
> 
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
>> Hi Philippe,
>>
>> I'm trying to understand the reasoning for moving inband work struct for
>> the remaining cases of the triggering stack.
>>
>> To my understanding, this is not needed for xnthread_map (to be
>> privatized soon, so only for the in-tree case) because the caller
>> providing the struct waits for the completion which will be triggered
>> via the inband handler.
>>
> 
> Correct.
> 
>> Looking at xnthread_relax(), the same should apply to post_wakeup -
>> provided it is inlined into xnthread_relax - because, again, we won't
>> leave that function before the signal was sent, thus the work consumed.
>>
> 
> Correct.
> 
>> Am I missing something?
>>
> 
> Nope.
> 

Perfect.

I'm finalizing the patches to merge dovetail completely into next. With
your unicore-SMP fix, we should even get a green test pipeline soon.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux