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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
