[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: [patch] fastcall-2.3.32-B6, SYSENTER/SYSEXIT support
From:       jg () pa ! dec ! com (Jim Gettys)
Date:       1999-12-20 20:10:13
[Download RAW message or body]


> From: Linus Torvalds <torvalds@transmeta.com>

> > 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/

[prev in list] [next in list] [prev in thread] [next in thread]