100ms timer resolution isn't great for applications that are
interacting with the real world. 1ms starts to be more useful
for process control.
Changing HZ to 1000 and recompiling seems to work fine. I assume
that any pre-compiled binaries using HZ will be wrong, but how
bad can it be?
I don't know if Rubini's book reflects the views of this list,
but he suggests that udelay() is good for dealing with hardware
and that a 100ms jiffie is good enough for dealing with wetware
(people), and what else could you want? In our case, access
to time delays at the resolution supported by the hardware clock.
I understand that this may have negative impacts on performance,
but the user is the person to decide what performance vs.
functionality they need, the kernels will/would continue to
ship with defaults appropriate for most users.
2) Is a timeslice == a timer tick?
3) There doesn't seem any way to include the right header so
that struct itimerspec is defined for applications. Since I've
implemented a version of the POSIX.4 timer_* calls, this is a
pain.
POSIX.4 wants struct timespec, itimerspec, clockid_t, and timer_t
all to be defined by including <time.h>. Any suggestions/chance
at getting them there?
4) Where has all the POSIX.4 gone?
It appears that the alpha port has POSIX.4 timers and there is
at least kernel support for queued/real-time signals. I haven't
been able to see from the man pages whether this support extends
into the application libraries, or test the queuing mechanisms
yet.
I found patches for the posix.4 timer functions for intel platforms.
http://hegel.ittc.ukans.edu/projects/
Is anybody else interested in having the posix.4 timer functions
integrated into the mainstream kernel? They are useful for non-realtime
programs as well, they provide ways of getting the current timer
resolution in a way not depending on the HZ define (clock_getres()),
creating multiple timers, each of which runs seperately, and
can be set absolutely or relatively, each timeout can be delivered
to *any* signal (not just sigalrm).
Is there anybody actively working on implementing posix.4 timers in
the kernel?
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/