LWN: Comments on "Virtual time"

Virtual time

pm101 — Tue, 25 Apr 2006 02:14:10 +0000

From the other side of the equation, I would like to use this for avoiding timeouts. Quite a few applications time out after some time. I've even had free software applications tell me "You're running a version of XXXX, please upgrade." I've also had restricted materials time-out (in one case, a class distributed an educational application that stopped working when the semester ended). Bypassing these seems like a good and noble endeavor.

gettimeofday() --- Move the system call into userspace

Blaisorblade — Sat, 22 Apr 2006 08:33:06 +0000

That's indeed implement since some time (guess in the 2.5 era) in arch/x86_64/kernel/vsyscall.c, together with the time syscall and two empty slots.

Virtual time

skybrian — Sat, 22 Apr 2006 05:22:04 +0000

There's actually a good reason for "messing deeply with their idea of time": testing applications that use timeouts and schedulers. For example, suppose you want to see what happens after a month's worth of nightly batch processes have happened. It's useful to be able to speed up time so it doesn't actually take a month to run the test.

There are many ways to do this, but running software in fast-forward would be a useful tool in the application developer's toolkit.

gettimeofday() --- Move the system call into userspace

AnswerGuy — Fri, 21 Apr 2006 16:37:23 +0000

One novel approach to speeding up gettimeofday that I heard about a few
years ago (from Andrew Tridgell who implemented it on a different OS
and architecture) was to get ride of the gettimeofday() system call
entirely.

One model for doing this would be to use a read-only globally shared page which contained the current time (and things like the uname() struct pathconf() and sysconf() and whatever else will fit in one or two pages).

These pages are mapped into every process' address space (similar to how VDSO's are mapping a kernel hosted userspace threading library implementation --- but read-only rather than executable). Then the gettimeofday() and uname() and a few other system calls can be implemented in user space by he libraries without including any context switch overhead.

(Realistically you'd leave the system calls in for compatability but offer
a faster more lightweight method as described; perhaps adding printk() options to help identify those apps which were using the slower, heavyweight system call method).

One thing that's easy to misunderstand about UNIX is that the distinction between system call and library function can (from some perspective) be a bit arbitrary. Classically a system call is any function which interfaces to kernel space while library functions can be wrapped around system calls but are generally done entirely within a process' own address space (in user space). However, with some of the memory mapping tricks (and memory mapped I/O hardware features) it's possible for many operations that would conception involve system calls to be implemented as library functions with suitable memory mappings.

This is not to say that such memory mappings are "better" than system calls in the general case. However, for some things like gettimeofday() and uname() there is a pretty clear win on (almost?) any modern virtual memory architecture.

JimD