> > I think you should concentrate on read(), write() and select()
> > syscalls. Those are the ones done often.
Yup. These are the ones X cares about most.
In particular, X seldom has more than a few simultaneously active clients:
the case to optimize for is select, where most connections are idle at
any given instant; the number of clients, however, seems to have doubled
in modern desktops (Gnome/KDE) over my previous observations over the
history of X; it isn't unusual for there to be 30-60 connections open
simultaneously these days (mostly idle). Some are the new geegaws, and
some are the natural tendency to have more useful applets than we used
to have (e.g. not just clock, but PPP connection state, MP3 player, etc.).
Alot of the current "bad behavior" of X servers under load from multiple
clients will be getting fixed in XFree86 4.0, with Keith Packard's new
X scheduler and "silken mouse" code.
>
> I mostly agree, although gettimeofday() under X is actually _the_ most
> common one. But gettimeofday() is special anyway, simply because it
> doesn't actually need to do a kernel entry, so the three you mention are
> certainly "basic".
>
Time of day is needed for a couple of things:
1) ideally, if really cheap, it ought to be folded into the
user mode schedular that X has internally. It isn't cheap enough
today to do so on most platforms, so Keith avoided it in his new
schedular, but someday...
Note that the inner loop of an X server is of order 100 or less
instructions (I don't have current cycle counts); it really is
performance sensitive in there.
2) timestamps are needed on events to resolve race conditions
that will otherwise occur. One of the mistakes in X11 design
is that there are a few event types that do NOT have timestamps (and
therefore some unresolvable races). Note that some of the
recent window managers have not been paying attention to these,
which accounts for the sometimes unexpected behavior they exhibit:
machines are now fast enough they "usually" get away with it, though
I think they'd do better if the authors read the protocol again...
Paying attention to timestamps in particular would help window
manager behavior on a loaded system when there are system schedular
delays.
My solution for the need to get the time alot on Digital UNIX was to put
the current system time into a piece of shared memory provided by the
generic X device driver I designed, so the X server could read it without
a system call. I dunno if other UNIX vendors did anything similar; as
it was only a few lines of code since I implemented a shared memory device
queue, it was worthwhile.
Given that machines are so much faster, I don't think the measures I took
to implement shared memory with the generic X driver are needed anymore
(1 mip machines were when it made a really significant difference in "feel"),
so long as we can get all input events timestamped as they are queued;
it does present the X server with the need to read all input devices at
once and sort by timestamp to get it all right though.
Note that gettimeofday is also heavily used for benchmarking and for
user land scheduling: something more generic than the device driver
solution I did is probably warranted.
- 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/