GitLab

Timers may have specific CPU affinity requirements in that their
backing clock device might not beat on all available CPUs, but only on
a subset of them.

The CPU affinity of every timer bound to a particular thread has to be
tracked each time such timer is started, so that no core timer is
queued to a per-CPU list which won't receive any event from the
backing clock device.

Such tracking was missing for timerfd and POSIX timers, along with
internal timers running the sporadic scheduling policy.

At this chance, the timer affinity code was cleaned up by folding all
the affinity selection logic into a single call,
i.e. xntimer_set_affinity().

Greg Gallagher authored Dec 04, 2017 and Philippe Gerum committed Dec 05, 2017

split rtdm_fd_enter, move the functionality where we store the fd
until after the open() call succeeds.  Calls where open() fail a fd is
left in the tree even after the cleanup code is executed.  If this fd
number is used again we will fail the call to open until a different
fd is used.  This patch addresses this situation by not adding the fd
into the tree until open has succeeded and the fd is valid.

Same as e6cd9610.

Unless explicitly paired with access_w/rok() checks, all copy to/from
helpers should implement the safe form, testing for the basic sanity
of the address range.

cobalt_copy_to/from_user() implement the safe call form in replacement
of __xn_safe_copy_to/from_user(). __xn_copy_to/from_user() still
implement the unchecked variant, assuming the address range will be
checked separately.

Drivers should stick with the rtdm_copy_to/from_user() helpers.

Jan Kiszka authored Feb 12, 2015 and Philippe Gerum committed Feb 13, 2015

Remove the return type from COBALT_SYSCALL[_DECL] and replace it with
long, the correct type we actually need to provide to the syscall
dispatchers. Convert all users of the macros. This has to be done in a
single step, thus this huge commit.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

this makes changing the O_NONBLOCK flag possible with fcntl

Use regular kernel file descriptors for all kinds of connection
handles, referring to regular file objects:

- connection to devnode => filp on chrdev inode
- socket => filp on anon inode

User and kernel-originated connection handles are no more
differenciated.

The former procfs interface for RTDM is now entirely gone, as all file
descriptors are now visible from /proc/<pid>/fd.

Obtaining the list of all named devices can be done this way:

$ grep named /sys/class/rtdm/*/flags

Similarly, the list of all protocol devices can be obtained this way:

$ grep protocol /sys/class/rtdm/*/flags

Force closing a stuck file descriptor (formerly done by writing to
rtdm/open_fildes) makes no sense anymore. Either the owner is a
userland process and all file handles it holds will be automatically
dropped at exit, or it is a kernel driver, in which case the driver
direly needs fixing.

Except in the only weird case of forcing a close on any random
kernel-originated connection through the procfs interface
(open_fildes), but this case is on its way out.

For the sake of mental sanity, we really want to assume that only the
current thread may affect its own file table, which is what this patch
enforces.

The rtdm_fd cleanup thread is a non-issue, as we are not supposed to
run any fd ops recursively on behalf of a ->close() handler anyway.

This change also fixes a rampant inconsistency where a Cobalt user
thread running some driver code would actually look up into the wrong
RTDM file table when using the rt_dev_* interface
(i.e. __xnsys_global_ppd would not be the right context in such a
case).

For consistency with timer_settime(), and also because the current
thread is assumed to receive the notifications if TFD_WAKEUP is set.

Since all userland processes belong to the Cobalt personality, all
syscalls have been merged into the Cobalt table.

As a consequence, all process context information maintained by the
core has moved to the cobalt_process descriptor.

For consistency, the related ancillary services from the RTDM layer
have been renamed accordingly.

Change the affinity target from a thread to a scheduler slot for
initializing timers, since this is the information we need in the
end.

In addition, we might race with a target thread vanishing on a remote
CPU in some cases, which can't happen with scheduler slots.

Applying a single gravity value for anticipating on all timer shots -
regardless of what the issuing timer is being used for - falls short
of considering the proper latency attached to the context. This leads
to poor tuning, with either negative latencies (i.e. early shots)
observed on measuring the jitter for irq handlers, or higher latencies
than expected for user-space threads when using too optimistic
(i.e. small) clock gravities.

Typically, the distance between the core clock handler and the
associated kernel-based handler the former calls, is much shorter than
what has to be traversed for switching in a kernel thread. It is even
shorter than the latency incurred for switching a user-space thread
from the core clock handler.

To solve this, we differentiate timers on the final context they
activate, between irq(handler), kernel and user threads, using the
appropriate gravity value when planning for the next shot, on a
per-timer basis, instead of using a single per-clock gravity as
previously.

Two additional contexts (irq and kernel) are added to the clock
gravity settings. The user can pass a hint to xntimer_init() for
indicating which kind of context will be activated by this timer (see
XNTIMER_[IKU]GRAVITY).

There are side-effects for this change on the procfs support:

- the information previously available from the xenomai/timer entry is
  now obtained by reading xenomai/clock/coreclk. In addition, the
  clock gravity values are reported.

- the former contents of xenomai/clock/* entries (i.e. the list of
  active timers running on the associated clock) is now available from
  the new xenomai/timer/* entries, also indexed on the clock name.

Writing to an entry under xenomai/clock/* can be used to change the
gravity values of the associated clock.

/* change the user gravity (default) */
echo 3000 > /proc/xenomai/clock/coreclck
/* change the IRQ gravity */
echo 1000i > /proc/xenomai/clock/coreclck
/* change the user and kernel gravities */
echo "2000u 1000k" > /proc/xenomai/clock/coreclck

Gilles Chanteperdrix authored Jun 01, 2014 and Philippe Gerum committed Jun 02, 2014

Because timer period is converted to clock ticks when starting a
periodic timer, round-off errors may accumulate at each timer tick
causing the timer to drift. Fix this by keeping the timer period as a
count of nanoseconds and convert to clock ticks at each period. This
adds some overhead, but is more correct.