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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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   [email protected]
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux