cvs commit: src/sys/sys time.h src/sys/kern kern_time.c

[Robert Watson]

On Mon, 28 Nov 2005, Bruce Evans wrote:

>> is something I'm quite willing to discuss, but the evidence seems to 
>> suggest that if we want to improve the performance of this class of 
>> applications, we need to provide time keeping services that match their 
>> requirements (run frequently with fairly weak requirements on 
>> precision). I'm entirely open to exposing this service in different 
>> ways, or offering a different notion of "cheaper, suckier".  For 
>> example, I could imagine exposing an interface intended to return 
>> timing information specifically for HZ-driven sleep mechanisms, such as 
>> poll() and select(). The advantage, for experimental purposes, in the 
>> approach I committed is that it allows us to easily test the impact of 
>> such changes on applications without modifing the application.  The 
>> disadvantage is that we'll want to change it, but given that I am not 
>> yet clear we fully understand the requirements, that is probably 
>> inevitable.
>
> The environment variable (or a sysctl/sysconf variable like 
> vfs.timestamp_ precision but per-process or per-user) is probably 
> needed, since you don't want to teach all applications about unportable 
> CLOCK_*.

This is an interesting issue, and one I have conflicted feelings about. 
On the one hand, introducing non-portable interfaces to implement what 
applications expect from portable ones has a certain bad feeling to it 
(and negative implications for how applications behave when not properly 
adapted). On the other hand, our ports system is all about adapting 
applications to run and package properly on FreeBSD, and modern "portable" 
applications achieve their portabability through extensive localization to 
each target platform.  I.e., we can actually expect that for particularly 
performance-sensitive adaptations, minor changes such as changing the 
clockid_t passed to a time call in order to optimize critical runloops can 
be done.  Likewise, we can hope to influence important service libraries, 
such as X client libraries, libisc, libevent, and so on.  So the idea that 
we can affect some critical applications is somewhat realistic.

For example, the MySQL port already contains fairly extensive 
this-and-that in order to make it work on FreeBSD at all well (for 
example, linking against LinuxThreads).  Likewise, other key applications 
such as Apache have FreeBSD customizations to use accept filters, and 
still others are tweaked to use kqueue.  I started reading through MySQL 
source code a few days ago to learn more about how time stamps are 
actually used, and discovered that they are used for a lot of things -- 
some for event model stuff (such as for calls into select()), but in other 
places for internal performance measurement or to allow useful time stamps 
to be preserved in data records.  This suggests to me that the best place 
to make the quality selection is in the application or framework itself, 
not on a per-process or per-application basis -- we can provide a knob to 
support that where the application isn't adapted, but having applications 
adapted makes a fair amount of sense if they are performance critical and 
widespread.

None of this helps us with kernel time measurement and context switch 
costs, though, which still need to be addressed.

Robert N M Watson