Turns out that user mode schedulers, such as we'd like to be able to
implement in an X server, also need the CPU time used by the process/thread
to work best (I'd like to be able to keep track of how much CPU time a
given client is using). On more modern processors, there may be processor
registers that may allow access to such times *VERY* cheaply; so
of course, it should be hidden behind a procedure call (which might
be inligned appropriately on certain platforms). This is closely
related to the kinds of information that really good profiling systems
such as DCPI need.
But again, it needs to be *REALLY* cheap to enable good scheduling policies
in application servers such as X (which probably has the most agressive
performance requirements of any I'm aware of).
At least X events are relatively heavyweight items that may result in
a context switch (not necessarily), so doing a system call to get the
time of day isn't a huge problem. Bit since the X server is prone even
to paging, it is in fact best if incoming pointer move events get timestamped
when they arrive in the device driver: there is no guarantee that the X
server will get run each time one runs, and there is variable latency until
the X server runs, so doing a system call to get the time introduces unknown
amounts of latency to event time stamping; the X server may run well
behind when new events are generated.
So in fact, I'm most interested in cheap time of day and process time
for the internals of an X server schedular rather than any overhead in
getting timestamps for events.
- Jim
-- Jim Gettys Technology and Corporate Development Compaq Computer Corporation jg@pa.dec.com
- 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/