Am 05.10.2010 16:21, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Am 05.10.2010 15:50, Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Am 05.10.2010 15:42, Gilles Chanteperdrix wrote:
>>>>> Jan Kiszka wrote:
>>>>>> Am 05.10.2010 15:15, Gilles Chanteperdrix wrote:
>>>>>>> Jan Kiszka wrote:
>>>>>>>> Hi,
>>>>>>>> quite a few limitations and complications of using Linux services over
>>>>>>>> non-Linux domains relate to potentially invalid "current" and
>>>>>>>> "thread_info". The non-Linux domain could maintain their own kernel
>>>>>>>> stacks while Linux tend to derive current and thread_info from the 
>>>>>>>> stack
>>>>>>>> pointer. This is not an issue anymore on x86-64 (both states are stored
>>>>>>>> in per-cpu variables) but other archs (e.g. x86-32 or ARM) still use 
>>>>>>>> the
>>>>>>>> stack and may continue to do so.
>>>>>>>> I just looked into this thing again as I'm evaluating ways to exploit
>>>>>>>> the kernel's tracing framework also under Xenomai. Unfortunately, it
>>>>>>>> does a lot of fiddling with preempt_count and need_resched, so patching
>>>>>>>> it for Xenomai use would become a maintenance nightmare.
>>>>>>>> An alternative, also for other use cases like kgdb and probably perf, 
>>>>>>>> is
>>>>>>>> to get rid of our dependency on home-grown stacks. I think we are on
>>>>>>>> that way already as in-kernel skins have been deprecated. The only
>>>>>>>> remaining user after them will be RTDM driver tasks. But I think those
>>>>>>>> could simply become in-kernel shadows of kthreads which would bind 
>>>>>>>> their
>>>>>>>> stacks to what Linux provides. Moreover, Xenomai could start updating
>>>>>>>> "current" and "thread_info" on context switches (unless this already
>>>>>>>> happens implicitly). That would give us proper contexts for 
>>>>>>>> system-level
>>>>>>>> tracing and profiling.
>>>>>>>> My key question is currently if and how much of this could be realized
>>>>>>>> in 2.6. Could we drop in-kernel skins in that version? If not, what
>>>>>>>> about disabling them by default, converting RTDM tasks to a
>>>>>>>> kthread-based approach, and enabling tracing etc. only in that case?
>>>>>>>> However, this might be a bit fragile unless we can establish
>>>>>>>> compile-time or run-time requirements negotiation between Adeos and its
>>>>>>>> users (Xenomai) about the stack model.
>>>>>>> A stupid question: why not make things the other way around: patch the
>>>>>>> current and current_thread_info functions to be made I-pipe aware and
>>>>>>> use an "ipipe_current" pointer to the current thread task_struct. Of
>>>>>>> course, there are places where the current or current_thread_info macros
>>>>>>> are implemented in assembly, so it may be not simple as it sounds, but
>>>>>>> it would allow to keep 128 Kb stacks if we want. This also means that we
>>>>>>> would have to put a task_struct at the bottom of every Xenomai task.
>>>>>> First of all, overhead vs. maintenance. Either every access to
>>>>>> preempt_count() would require a check for the current domain and its
>>>>>> foreign stack flag, or I would have to patch dozens (if that is enough)
>>>>>> of code sites in the tracer framework.
>>>>> No. I mean we would dereference a pointer named ipipe_current. That is
>>>>> all, no other check. This pointer would be maintained elsewhere. And we
>>>>> modify the "current" macro, like:
>>>>> #ifdef CONFIG_IPIPE
>>>>> extern struct task_struct *ipipe_current;
>>>>> #define current ipipe_current
>>>>> #endif
>>>>> Any calll site gets modified automatically. Or current_thread_info, if
>>>>> it is current_thread_info which is obtained using the stack pointer mask
>>>>> trick.
>>>> The stack pointer mask trick only works with fixed-sized stacks, not a
>>>> guaranteed property of in-kernel Xenomai threads.
>>> Precisely the reason why I propose to replace it with a global variable
>>> reference, or a per-cpu variable for SMP systems.
>> Then why is Linux not using this in favor of the stack pointer approach
>> on, say, ARM?
>> For sure, we can patch all Adeos-supported archs away from stack-based
>> to per-cpu current & thread_info, but I don't feel comfortable with this
>> in some way invasive approach as well. Well, maybe it's just my personal
>> misperception.
> It is as much invasive as modifying local_irq_save/local_irq_restore.
> The real question about the global pointer approach, is, if it so much
> less efficient, how does Xenomai, which uses this scheme, manage to have
> good performances on ARM?

Xenomai has no heavily-used preempt_disable/enable that is built on top
of thread_info. But I also have no numbers on this.

I looked closer at the kernel dependencies on a fixed stack size.
Besides current and thread_info, further features that make use of this
are stack unwinding (boundary checks) and overflow checking. So while we
can work around the dependency for some tracing requirements, I really
see no point in heading for this long-term. It just creates more subtle
patching needs in Adeos, and it also requires work on Xenomai side. I
really think it's better provide a compatible context to reduce
maintenance efforts.

So I played a bit with converting RTDM tasks to in-kernel shadows. It
works but needs more fine-tuning. My proposal for 2.6 now looks like this:

 - add mm-less shadow support to the nucleus (changes in
   xnarch_switch_to and xnshadow_map)
 - convert RTDM tasks to in-kernel shadows
 - switch current and thread_info on Xenomai task switches
 - make in-kernel skins optional, default off
 - let in-kernel skins dependent on disabled tracing


Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Xenomai-core mailing list

Reply via email to