Re: domain switch
Sorry for the inconvenience,
I tried to write this code to report domain changes (or mode switch):
##
#include
#include
#include
#include
#include
#include
RT_TASK task;
void task_body(void *arg)
{
RT_TASK_INFO info;
printf("Hello\n");
rt_printf("ByeBye\n");
rt_task_inquire(NULL, &info);
rt_printf("mode switch = %d\n", info.stat.msw);
}
int main()
{
int err;
err = rt_task_create(&task, "mytask", 0, 1, 0);
if (err != 0){
fprintf(stderr, "failed to create task\n");
exit(EXIT_FAILURE);
}
err = rt_task_start(&task, &task_body, NULL);
if (err != 0){
fprintf(stderr, "failed to start task\n");
exit(EXIT_FAILURE);
}
pause();
exit(EXIT_SUCCESS);
}
##
but I get 0 as a result. How is this possible?
Il giorno dom 3 gen 2021 alle ore 12:20 Leandro Bucci <
guestleandr...@gmail.com> ha scritto:
> perfect thank you so much for the explanation
>
> Il dom 3 gen 2021, 12:06 Philippe Gerum ha scritto:
>
>>
>> Leandro Bucci writes:
>>
>> > is it possible to have the same thing for tasks instead of threads?
>> >
>>
>> task == thread
>>
>> > Il dom 3 gen 2021, 11:31 Philippe Gerum ha scritto:
>> >
>> >>
>> >> steve freyder via Xenomai writes:
>> >>
>> >> > Right.
>> >> >
>> >> >
>> >> > AKA, "mode switch", a switch from "primary mode" to "secondary mode",
>> >> > or vice versa.
>> >> >
>> >> > One place you can find that information is in:
>> >> >
>> >> > /proc/xenomai/sched/acct
>> >> >
>> >> > there are two fields MSW, and CSW which count mode/context switches
>> >> > per-process. This requires an open, a read loop to locate the desired
>> >> > pid and extract the desired information, then either rewind or
>> >> > close/reopen to do it again - all of which will almost surely
>> generate
>> >> > more mode/context switching.
>> >> >
>> >>
>> >> If that helps, there is also the option of getting the thread stats by
>> >> program, using int cobalt_thread_stat(pid_t pid, struct
>> >> cobalt_threadstat *stat), declared in sys/cobalt.h. pid refers to a
>> >> thread identifier (as obtained from gettid(2) in the context of the
>> >> target thread). It must refer to a Cobalt thread, otherwise the call
>> >> would fail with -ESRCH.
>> >>
>> >> The mode switch count is present in the returned information block
>> >> (->msw). cobalt_thread_stat() would not cause any mode switch. It can
>> be
>> >> called by any thread regardless of its type (i.e. regular or Cobalt).
>> >>
>> >> --
>> >> Philippe.
>> >>
>>
>>
>> --
>> Philippe.
>>
>
Re: domain switch
perfect thank you so much for the explanation Il dom 3 gen 2021, 12:06 Philippe Gerum ha scritto: > > Leandro Bucci writes: > > > is it possible to have the same thing for tasks instead of threads? > > > > task == thread > > > Il dom 3 gen 2021, 11:31 Philippe Gerum ha scritto: > > > >> > >> steve freyder via Xenomai writes: > >> > >> > Right. > >> > > >> > > >> > AKA, "mode switch", a switch from "primary mode" to "secondary mode", > >> > or vice versa. > >> > > >> > One place you can find that information is in: > >> > > >> > /proc/xenomai/sched/acct > >> > > >> > there are two fields MSW, and CSW which count mode/context switches > >> > per-process. This requires an open, a read loop to locate the desired > >> > pid and extract the desired information, then either rewind or > >> > close/reopen to do it again - all of which will almost surely generate > >> > more mode/context switching. > >> > > >> > >> If that helps, there is also the option of getting the thread stats by > >> program, using int cobalt_thread_stat(pid_t pid, struct > >> cobalt_threadstat *stat), declared in sys/cobalt.h. pid refers to a > >> thread identifier (as obtained from gettid(2) in the context of the > >> target thread). It must refer to a Cobalt thread, otherwise the call > >> would fail with -ESRCH. > >> > >> The mode switch count is present in the returned information block > >> (->msw). cobalt_thread_stat() would not cause any mode switch. It can be > >> called by any thread regardless of its type (i.e. regular or Cobalt). > >> > >> -- > >> Philippe. > >> > > > -- > Philippe. >
Re: domain switch
Leandro Bucci writes: > is it possible to have the same thing for tasks instead of threads? > task == thread > Il dom 3 gen 2021, 11:31 Philippe Gerum ha scritto: > >> >> steve freyder via Xenomai writes: >> >> > Right. >> > >> > >> > AKA, "mode switch", a switch from "primary mode" to "secondary mode", >> > or vice versa. >> > >> > One place you can find that information is in: >> > >> > /proc/xenomai/sched/acct >> > >> > there are two fields MSW, and CSW which count mode/context switches >> > per-process. This requires an open, a read loop to locate the desired >> > pid and extract the desired information, then either rewind or >> > close/reopen to do it again - all of which will almost surely generate >> > more mode/context switching. >> > >> >> If that helps, there is also the option of getting the thread stats by >> program, using int cobalt_thread_stat(pid_t pid, struct >> cobalt_threadstat *stat), declared in sys/cobalt.h. pid refers to a >> thread identifier (as obtained from gettid(2) in the context of the >> target thread). It must refer to a Cobalt thread, otherwise the call >> would fail with -ESRCH. >> >> The mode switch count is present in the returned information block >> (->msw). cobalt_thread_stat() would not cause any mode switch. It can be >> called by any thread regardless of its type (i.e. regular or Cobalt). >> >> -- >> Philippe. >> -- Philippe.
Re: domain switch
is it possible to have the same thing for tasks instead of threads? Il dom 3 gen 2021, 11:31 Philippe Gerum ha scritto: > > steve freyder via Xenomai writes: > > > Right. > > > > > > AKA, "mode switch", a switch from "primary mode" to "secondary mode", > > or vice versa. > > > > One place you can find that information is in: > > > > /proc/xenomai/sched/acct > > > > there are two fields MSW, and CSW which count mode/context switches > > per-process. This requires an open, a read loop to locate the desired > > pid and extract the desired information, then either rewind or > > close/reopen to do it again - all of which will almost surely generate > > more mode/context switching. > > > > If that helps, there is also the option of getting the thread stats by > program, using int cobalt_thread_stat(pid_t pid, struct > cobalt_threadstat *stat), declared in sys/cobalt.h. pid refers to a > thread identifier (as obtained from gettid(2) in the context of the > target thread). It must refer to a Cobalt thread, otherwise the call > would fail with -ESRCH. > > The mode switch count is present in the returned information block > (->msw). cobalt_thread_stat() would not cause any mode switch. It can be > called by any thread regardless of its type (i.e. regular or Cobalt). > > -- > Philippe. >
Re: domain switch
steve freyder via Xenomai writes: > Right. > > > AKA, "mode switch", a switch from "primary mode" to "secondary mode", > or vice versa. > > One place you can find that information is in: > > /proc/xenomai/sched/acct > > there are two fields MSW, and CSW which count mode/context switches > per-process. This requires an open, a read loop to locate the desired > pid and extract the desired information, then either rewind or > close/reopen to do it again - all of which will almost surely generate > more mode/context switching. > If that helps, there is also the option of getting the thread stats by program, using int cobalt_thread_stat(pid_t pid, struct cobalt_threadstat *stat), declared in sys/cobalt.h. pid refers to a thread identifier (as obtained from gettid(2) in the context of the target thread). It must refer to a Cobalt thread, otherwise the call would fail with -ESRCH. The mode switch count is present in the returned information block (->msw). cobalt_thread_stat() would not cause any mode switch. It can be called by any thread regardless of its type (i.e. regular or Cobalt). -- Philippe.
Re: domain switch
Awesome, thanks! Il dom 3 gen 2021, 00:06 steve freyder ha scritto: > Right. > > > AKA, "mode switch", a switch from "primary mode" to "secondary mode", or > vice versa. > > One place you can find that information is in: > > /proc/xenomai/sched/acct > > there are two fields MSW, and CSW which count mode/context switches > per-process. This requires an open, a read loop to locate the desired pid > and extract the desired information, then either rewind or close/reopen to > do it again - all of which will almost surely generate more mode/context > switching. > > > On 1/2/2021 2:54 PM, Leandro Bucci via Xenomai wrote: > > Hi, I wanted to know if there was a way to count the number of times a > domain switch happens. > For example the printf () function causes a domain switch, right? > >
Re: domain switch
Right. AKA, "mode switch", a switch from "primary mode" to "secondary mode", or vice versa. One place you can find that information is in: /proc/xenomai/sched/acct there are two fields MSW, and CSW which count mode/context switches per-process. This requires an open, a read loop to locate the desired pid and extract the desired information, then either rewind or close/reopen to do it again - all of which will almost surely generate more mode/context switching. On 1/2/2021 2:54 PM, Leandro Bucci via Xenomai wrote: Hi, I wanted to know if there was a way to count the number of times a domain switch happens. For example the printf () function causes a domain switch, right?
domain switch
Hi, I wanted to know if there was a way to count the number of times a domain switch happens. For example the printf () function causes a domain switch, right?
Re: Task Priority & Domain switch
On 05.09.19 15:26, Johann Obermayr via Xenomai wrote: Hello, i need some explain about task priority & domain switch. 1. Xenomai 2.6.x ( CONFIG_XENO_OPT_PERVASIVE=yCONFIG_XENO_OPT_PRIOCPL=y ) Don't enable XENO_OPT_PRIOCPL. It was never working as expected (best case) or was even causing more major issues (source of many crashes). rt_task_shadow( &handle, 0 ); task running default in releaxed ( secondary domain). After take a xenomai mutex lock, it switch to the primary domain. After mutex unlock the task switch back to secondary domain or after next xenomai-function call ? Immediately for SCHED_OTHER threads (prio 0). RT threads are switched back to RT lazily, i.e. when the next RT syscall is issued. rt_task_shadow( &handle, 10 ); task run default in primary domain. After do a linux-syscall , the task switch to secondary domain. With XENO_OPT_PRIOCPL it take the xenomai priority 10 to Linux rt_priority 10. After call a xenomai function, it switch back to primary domain. 1. Xenomai 3.0.x Is there a different work to xenomai 2.6.x ? Or where can I found more information about this theme ? See the section on SCHED_WEAK in https://gitlab.denx.de/Xenomai/xenomai/wikis/Migrating_From_Xenomai_2_To_3. Thanks & regards Johann PS: I known that xenomai 2.6.x is out of date. But we must support some old versions. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Task Priority & Domain switch
Hello, i need some explain about task priority & domain switch. 1. Xenomai 2.6.x ( CONFIG_XENO_OPT_PERVASIVE=yCONFIG_XENO_OPT_PRIOCPL=y ) rt_task_shadow( &handle, 0 ); task running default in releaxed ( secondary domain). After take a xenomai mutex lock, it switch to the primary domain. After mutex unlock the task switch back to secondary domain or after next xenomai-function call ? rt_task_shadow( &handle, 10 ); task run default in primary domain. After do a linux-syscall , the task switch to secondary domain. With XENO_OPT_PRIOCPL it take the xenomai priority 10 to Linux rt_priority 10. After call a xenomai function, it switch back to primary domain. 1. Xenomai 3.0.x Is there a different work to xenomai 2.6.x ? Or where can I found more information about this theme ? Thanks & regards Johann PS: I known that xenomai 2.6.x is out of date. But we must support some old versions.
Re: [Xenomai] mmap and domain switch
On 11/26/2013 12:20 PM, Giuseppe Iellamo wrote: Hi all, In my project I'm accessing a device using a linux device driver (via sysfs) . In order to speedup the control loop I've mmapped the register i need to read. The question is: If I access a device register using mmap assuming you mean "mmaped memory" here, from a xenomai task am i triggering a domain switch ? No, unless you take a fault doing so, which should not happen if the MMR is properly mapped/accessed. BR, Giuseppe ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
[Xenomai] mmap and domain switch
Hi all, In my project I'm accessing a device using a linux device driver (via sysfs) . In order to speedup the control loop I've mmapped the register i need to read. The question is: If I access a device register using mmap from a xenomai task am i triggering a domain switch ? BR, Giuseppe ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
