Messages in this thread | | | Date | Thu, 30 Dec 1999 11:19:33 -0800 (PST) | From | (Jim Gettys) | Subject | Re: [patch] fastcall-2.3.32-B6, SYSENTER/SYSEXIT support |
| |
> Sender: owner-linux-kernel@vger.rutgers.edu > From: Linus Torvalds <torvalds@transmeta.com> > Date: Tue, 14 Dec 1999 13:23:41 -0800 (PST) > To: Alexander Viro <viro@math.psu.edu> > Cc: Pavel Machek <pavel@suse.cz>, Ingo Molnar <mingo@chiara.csoma.elte.hu>, > Artur Skawina <skawina@geocities.com>, > "linux-kernel@vger.rutgers.edu" <linux-kernel@vger.rutgers.edu> > Subject: Re: [patch] fastcall-2.3.32-B6, SYSENTER/SYSEXIT support > ----- > On Tue, 14 Dec 1999, Alexander Viro wrote: > > > > On Tue, 14 Dec 1999, Linus Torvalds wrote: > > > > > I mostly agree, although gettimeofday() under X is actually _the_ most > > > common one. > > > > ??? Are you serious? What is it used for? > > Timestamping all the events. > > This is not that uncommon - there's a LOT of programs that care deeply > about wall-clock time. You'll find a few games avoid system calls like the > plague, but still call gettimeofday() because it's _really_ important to > know how time progresses.. >
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/
| |