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
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.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds