---
title: "Making Time to Save You Time: How We Sped Up Time-Related Syscalls on Dynos"
description: "A customer support ticket exposed poor performance in clock_gettime(3) and gettimeofday(2) for an application making many timing calls through transaction tracing. Heroku's Runtime Infrastructure team found that Linux was selecting the Xen clocksource, whose Xen version did not support virtual dynamic shared object (vDSO) acceleration, forcing costly userspace-to-kernel context switches. The team evaluated available clocksources and selected tsc, which uses the Time Stamp Counter and supports vDSO; they assessed concerns about backwards clock drift, including older CPU inconsistencies and Xen VM freezing, against their newer Intel CPUs and EC2 environment. After vdsotest validation, the configuration was deployed across the Common Runtime and Private Spaces dyno fleet, and the initiating customer plus other customers observed performance improvements."
---

# Making Time to Save You Time: How We Sped Up Time-Related Syscalls on Dynos

[Heroku](https://yomu.fyi/company/heroku) · Will Farrington · Jul 16, 2020

**Type:** Problem & solution

## Summary

A customer support ticket exposed poor performance in clock\_gettime(3) and gettimeofday(2) for an application making many timing calls through transaction tracing. Heroku's Runtime Infrastructure team found that Linux was selecting the Xen clocksource, whose Xen version did not support virtual dynamic shared object (vDSO) acceleration, forcing costly userspace-to-kernel context switches. The team evaluated available clocksources and selected tsc, which uses the Time Stamp Counter and supports vDSO; they assessed concerns about backwards clock drift, including older CPU inconsistencies and Xen VM freezing, against their newer Intel CPUs and EC2 environment. After vdsotest validation, the configuration was deployed across the Common Runtime and Private Spaces dyno fleet, and the initiating customer plus other customers observed performance improvements.

## Context

A customer reported poor performance in clock\_gettime(3) and gettimeofday(2), which an application used frequently for transaction tracing. The calls were slow because Linux selected the Xen clocksource, whose Xen version did not support vDSO acceleration, causing repeated userspace-to-kernel context switches.

## Approach / What changed

The team examined available clocksources, selected tsc to enable vDSO acceleration, and assessed potential backwards clock drift against Heroku's newer Intel CPUs and EC2 environment. They confirmed the result with vdsotest, then deployed the clocksource configuration to the Common Runtime and Private Spaces dyno fleet.

## Takeaways

- The Xen clocksource lacked vDSO support for clock\_gettime(3) and gettimeofday(2), so frequent calls incurred userspace-to-kernel context switches.
- The tsc clocksource uses the Time Stamp Counter and supports vDSO; Heroku considered older CPU inconsistencies and Xen VM freezing before selecting it.
- vdsotest confirmed vDSO acceleration before the tsc configuration was deployed across the Common Runtime and Private Spaces dyno fleet.

**Tags:** [Linux](https://yomu.fyi/topic/linux), [Performance](https://yomu.fyi/topic/performance)

- Source: [Heroku](https://www.heroku.com/blog/clocksource-tuning)
- Source URL: https://www.heroku.com/blog/clocksource-tuning
- Ingested by Yomu: 2026-09-09T16:05:14.464Z

[Read original post](https://www.heroku.com/blog/clocksource-tuning)