Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 455259 - More context for VDSO
Summary: More context for VDSO
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: Realtime_Tuning_Guide
Version: 1.0
Hardware: All
OS: Linux
Target Milestone: 1.1
: ---
Assignee: Lana Brindley
QA Contact: Jeff Needle
Depends On:
TreeView+ depends on / blocked
Reported: 2008-07-14 14:29 UTC by Carl Trieloff
Modified: 2013-10-23 23:08 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-11-25 01:54:24 UTC
Target Upstream Version:

Attachments (Terms of Use)

Comment 1 Lana Brindley 2008-07-14 23:53:20 UTC
Hi Clark,

Context please?


Comment 2 Clark Williams 2008-10-10 19:34:40 UTC
Ok, here's an initial stab at a fuller explanation of VDSOs (thanks for the clarification Luis!):

- From the


    Virtual Dynamically-linked Shared Object, a kernel-provided shared
    library that helps userspace perform a few kernel actions without
    the overhead of a system call, as well as automatically choosing
    the most efficient syscall mechanism. Also called the "vsyscall

The VDSO is a way for the Linux kernel to provide low-overhead access to certain data contained in user-space. The VDSO is mainly used to provide fast access to the gettimeofday(2) system call data.

The VDSO is enabled in one of two ways:

1. Passing the vdso= parameter on the kernel boot line with a non-zero argument
2. Writing a non-zero value into the /proc/sys/kernel/syscall64 proc filesystem entry of a running kernel

More on just what those non-zero values should be later.

The kernel VDSO actually overrides library entry points for any user-specified library. So, when you enable the VDSO, you're effectively telling the kernel to use it's definition of the symbols in the VDSO, rather than the ones found in user-space shared libraries (notably the GNU C library or glibc). Note that the effects of enabling the VDSO are system-wide; either all processes use it or they don't. 

The entry point provided by the VDSO that we're concerned with here is gettimeofday(2). When enabled, the kernel VDSO overrides the glibc definition of gettimeofday(2) with it's own and the system loader will use that address when dynamically loaded programs reference gettimeofday(2). What does your program need to do to use this? Nothing. You write your code to call gettimeofday() and link it normally (default linking action nowadays is to link to shared libraries). When your program is loaded by the system loader ( it will look first for the VDSO and if that's not available, it will search the C library and resolve the symbol there. 

Why would you want to enable the VDSO? If you are calling gettimeofday a lot, such as timestamping lots of network traffic, you may want to use the VDSO, since it removes the overhead of a system call from your program, since you're making a call directly to kernel memory, rather than going through the C library provided trap to kernel space. 

The value used to enable the VDSO affects the behavior of gettimeofday(2) on the MRG RT kernel. 

* echo 1 > /proc/sys/kernel/syscall64 (or boot with vdso=1)

  this option affects several time related functions behavior. All the calls
  to gettimeofday(2) are solved in userspace. The time granularity (i.e. the
  smallest interval you will be able to measure) is 1us (one microsecond).
  How it operates: the kernel maintains an internal variable that is
  updated every millisecond and when gettimeofday() is called, the clock is 
  read from userspace and the interval since last update is calculated (time

* echo 2 > /proc/sys/kernel/syscall64 (or boot with vdso=2)

  (note: this option is not available on RHEL5)
  this options differs from the latter because there is no clock reading at
  all. The variable updated by the kernel is read and its value is
  returned. This method presents a time granularity of 1ms. It is lower in
  overhead than method 1 but is less accurate.

Comment 3 Lana Brindley 2008-10-29 22:05:56 UTC
Due to be completed today and will be available for technical review tomorrow.


Comment 4 Lana Brindley 2008-10-30 05:42:18 UTC
Completed and available for review shortly.


Note You need to log in before you can comment on or make changes to this bug.