SWITCHTEST(1) Xenomai SWITCHTEST(1)NAME
switchtest - Xenomai context switch test
SYNOPSIS
switchtest [options] threadspec threadspec...
DESCRIPTION
switchtest is part of Xenomai. It can be used to test thread context switches. switchtest creates threads of various types and attempts to
switch context between these threads, printing the count of context switches every second. A suitable Xenomai enabled kernel with the
respective module (xeno_posix) must be installed.
OPTIONS
Each threadspec specifies the characteristics of a thread to be created:
threadspec = (rtk|rtup|rtus|rtuo)(_fp|_ufpp|_ufps)*[0-9]*
rtk for a kernel-space real-time thread
rtup for a user-space real-time thread running in primary mode
rtus for a user-space real-time thread running in secondary mode
rtuo for a user-space real-time thread oscillating between primary and secondary mode
_fp means that the created thread will have the XNFPU bit armed (only valid for rtk)
_ufpp means that the created thread will use the FPU when in primary mode0valid for rtus)
_ufps means that the created thread will use the FPU when in secondary mode (invalid for rtk and rtup)
[0-9]* specifies the ID of the CPU where the created thread will run, 0 if unspecified
Passing no threadspec is equivalent to running:
switchtest rtkN rtkN rtk_fpN rtk_fpN rtk_fp_ufppN rtk_fp_ufppN rtupN rtupN rtup_ufppN rtup_ufppN rtusN rtusN rtus_ufpsN rtus_ufpsN rtuoN
rtuoN rtuo_ufppN rtuo_ufppN rtuo_ufpsN rtuo_ufpsN rtuo_ufpp_ufpsN rtuo_ufpp_ufpsN
with N=1,...,nr_cpus, i.e. occurrences of all the arguments for each CPU
Passing only the --nofpu or -n argument is equivalent to running:
switchtest rtkN rtkN rtupN rtupN rtusN rtusN rtuoN rtuoN
similar to the above.
switchtest accepts the following options:
--help, -h
print usage information and exit
--lines <lines>, -l <lines>
print headers every <lines> lines
--quiet or -q
prevent this program from printing every second the count of ncontext switches
--timeout <duration>, -T <duration>
limit the test duration to <duration> seconds
--nofpu, -n
disables any use of FPU instructions
AUTHOR
switchtest was written by Philippe Gerum <rpm@xenomai.org> and Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>. This man page was
written by Roland Stigge <stigge@antcom.de>.
2.6.0 2008-04-19 SWITCHTEST(1)
Check Out this Related Man Page
MI_SWITCH(9) BSD Kernel Developer's Manual MI_SWITCH(9)NAME
mi_switch, cpu_switch, cpu_throw -- switch to another thread context
SYNOPSIS
#include <sys/param.h>
#include <sys/proc.h>
void
mi_switch(void);
void
cpu_switch(void);
void
cpu_throw(void);
DESCRIPTION
The mi_switch() function implements the machine independent prelude to a thread context switch. It is called from only a few distinguished
places in the kernel code as a result of the principle of non-preemptable kernel mode execution. The various major uses of mi_switch can be
enumerated as follows:
1. From within a function such as cv_wait(9), mtx_lock, or tsleep(9) when the current thread voluntarily relinquishes the CPU to wait
for some resource or lock to become available.
2. After handling a trap (e.g. a system call, device interrupt) when the kernel prepares a return to user-mode execution. This case
is typically handled by machine dependent trap-handling code after detection of a change in the signal disposition of the current
process, or when a higher priority thread might be available to run. The latter event is communicated by the machine independent
scheduling routines by calling the machine defined need_resched().
3. In the signal handling code (see issignal(9)) if a signal is delivered that causes a process to stop.
4. When a thread dies in thread_exit(9) and control of the processor can be passed to the next runnable thread.
5. In thread_suspend_check(9) where a thread needs to stop execution due to the suspension state of the process as a whole.
mi_switch() records the amount of time the current thread has been running in the process structures and checks this value against the CPU
time limits allocated to the process (see getrlimit(2)). Exceeding the soft limit results in a SIGXCPU signal to be posted to the process,
while exceeding the hard limit will cause a SIGKILL.
If the thread is still in the TDS_RUNNING state, mi_switch() will put it back onto the run queue, assuming that it will want to run again
soon. If it is in one of the other states and KSE threading is enabled, the associated KSE will be made available to any higher priority
threads from the same group, to allow them to be scheduled next.
After these administrative tasks are done, mi_switch() hands over control to the machine dependent routine cpu_switch(), which will perform
the actual thread context switch.
cpu_switch() first saves the context of the current thread. Next, it calls choosethread() to determine which thread to run next. Finally,
it reads in the saved context of the new thread and starts to execute the new thread.
cpu_throw() is similar to cpu_switch() except that it does not save the context of the old thread. This function is useful when the kernel
does not have an old thread context to save, such as when CPUs other than the boot CPU perform their first task switch, or when the kernel
does not care about the state of the old thread, such as in thread_exit() when the kernel terminates the current thread and switches into a
new thread.
To protect the runqueue(9), all of these functions must be called with the sched_lock mutex held.
SEE ALSO cv_wait(9), issignal(9), mutex(9), runqueue(9), tsleep(9), wakeup(9)BSD November 24, 1996 BSD