New watchdog handler implementation

[Sebastian Huber]

Hello,

for a proper timer support on SMP systems there is some work to do. I 
added a
ticket for this:

https://devel.rtems.org/ticket/2554

With respect to the data structure selection I think that the red-black 
trees
are a good choice.

An open issue is which load balancing and work distribution do we want 
to add.
Currently we have one watchdog header of the ticks based timers (relative
timeouts) and one for the seconds based timers (absolute timeouts). The 
timer
routines execute in the context of the clock tick interrupt of processor 
zero.
This is not scalable in the processor count.  It connects different 
scheduler
instances via this central infrastructure.

A simple enhancement would be to provide one watchdog header for

A) each scheduler instance, or

B) each processor.

I am in favour of option B), since

* the storage space for a watchdog header is quite small,

* access to the watchdog header is easy via the _Per_CPU_Information and
requires not dynamic memory, and

* schedulers supporting thread processor affinities could use a local 
watchdog
header.

Each watchdog header uses a dedicated lock.  Threads would use the watchdog
header of the current processor.  Access to the thread watchdog control is
protected by a dedicated lock in the thread control block.

Which watchdog header should be used in the timer objects?  Possible are

C) the watchdog header is determined at timer creation time, e.g. 
processor of
executing thread, or

D) selectable via new function, e.g. rtems_timer_set_processor().

I suggest to implement C) and D).  Is D) possible via POSIX API?

With the current clock drivers we must execute the clock interrupt service
routine on each processor all the time.  This is not very time and power
efficient.  The clock interrupt service on processor zero should execute all
the time, since otherwise the _Watchdog_Ticks_since_boot variable no longer
increments and this may confuse existing applications.  The clock interrupt
service on other processors should only execute in case their dedicated
watchdog set is not-empty.  Since this set changes dynamically, we must
regularly request the clock driver to disable/enable the clock interrupt
service execution on a particular processor.  I suggest to add a global 
clock
device handler table, which is initialized to a default and optionally 
replaced
by the clock driver providing the following handlers:

typedef struct {
   void (*enable_on_processor)(uint32_t processor);
   void (*disable_on_processor)(uint32_t processor);
} Clock_Device;

extern Clock_Device *_Clock_Device;

This could be enhanced to offer a tickless operation for systems 
sensitive to
power-consumption in the future.

Use of a global _Watchdog_Ticks_since_boot maintained by processor zero is a
bit problematic.  The clock interrupt service is triggered on different
processors simultaneously.  However, the clock interrupt service on 
processor
zero may be delayed due to various reasons, e.g. high priority nested
interrupt.  Thus the clock interrupt service on other processors would 
observe
a not up to date _Watchdog_Ticks_since_boot value.  So each watchdog header
must maintain its separate ticks value.  Some care must be taken to get the
start and stop tick values required for the timer objects.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.