Re: [patch 00/21] hrtimer - High-resolution timer subsystem

[George Anzinger]

Thomas Gleixner wrote:
> Hi,
~

> > This error is actually the expected behaviour for any timer with a 
> > resolution different from 1 nsec. I don't want to say that we can't have 
> > such a timer, but I'm not so sure whether this should be the default 
> > behaviour. I actually prefer George's earlier suggestion of CLOCK_REALTIME 
> > and CLOCK_REALTIME_HR, where one is possibly faster and the other is more 
> > precise. Even within the kernel I would prefer to map itimer and nanosleep 
> > to the first clock (maybe also based on arch/kconfig defaults).
> > OTOH if the hardware allows it, both clocks can do the same thing, but I 
> > really would like to have the possibility to give higher (and thus 
> > possibly more expensive) resolution only to those asking for it.
>
>
> Thats an rather odd approach for me. If we drag this further then we
> might consider that only some users (i.e. applications) of -rt patches
> are using the enhanced functionalities, which introduces interesting
> computational problems (e.g when to treat a mutex as a concurrency
> control which is capable of priority inversion or not). 

Er... what?  This is a non-compute.
> I vote strongly against introducing private, special purpose APIs and I
> consider CLOCK_XXX_HR as such. The proposed hrtimer solution does not
> introduce any penalties for people who do not enable a future high
> resolution extension. It gives us the benefit of a clean code base which
> is capable to be switched simply and non intrusive to the high
> resolution mode. We have done extensive tests on the impact of
> converting all users unconditionally to high resolution mode once it is
> switched on and the penalty is within the noise range. 
>
> You are explicitely asking for increased complexity with your approach. 

I beg to differ here.  The fact that high res timers, in general, 
require an interrupt per expiry, and that, by definition, we are 
changing the resolution by, I would guess, a couple of orders of 
magnitude implies a rather much larger over head.  If we sum this over 
all user timers it can IMHO get out of control.  Given that only a 
very small number of applications really need the extra resolution, I 
think it makes a lot of sense that those applications incur the 
overhead and others, which don't need nor want the higher resolution, 
just use the old low resolution timers.  The notion of switching this 
at configure time implies that a given kernel is going to be used ONLY 
one way or another for all applications, which, AFAICT is just not the 
way most users do things.

As to CLOCK_XXX_HR being a special purpose API, this is only half 
true.  It is a POSIX conforming extension and I do think you can find 
it used elsewhere as well.  On the other hand, it if you want to limit 
the higher overhead timers to only those who ask, well, I guess you 
could call that "special purpose".

On the complexity thing, your new organization makes the added 
"complexity" rather non-complex, in fact, you might say it is down 
right simple, for which, thank you.
>
~
--
George Anzinger   george@xxxxxxxxxx
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/