Feature #12345
closed
comm page should fallback to syscall after excessive migration
100%
Description
Copied from SmartOS OS-6135:
On platforms that have unsynchronized TSCs and lack support for the RDTSCP instruction, determining the TSC offset is a multi-step process. The current CPU ID is queried (via the lsl/GDT method), the TSC is read, then finally the CPU ID is re-checked in case a migration occurred. This is meant to ensure that the offset applied to the TSC reading corresponds to the CPU from which it was taken. If the CPU IDs don't match, the logic is repeated until it is successful.
While this ID-checking loop is rather tight, it can become a problem in certain circumstances. If the system is heavily loaded, migrations may occur rapidly. Any process "stuck" in this loop will represent an additional source of CPU load, potentially exacerbating the problem. It would be valuable to have bail-out logic to limit the loop iterations, perform the time reading via syscall if it cannot be completed by the userspace code in a timely manner.
Extensive testing notes are included in the comments of the ticket.
Related issues
Updated by Patrick Mooney over 3 years ago
- Related to Feature #7805: want faster clock_gettime added
Updated by Patrick Mooney over 3 years ago
- Related to Feature #11275: gettimeofday should use comm page added
Updated by Electric Monk over 3 years ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
git commit e121b61f5e8ffbeb2f6b373c967c80351333ee21
commit e121b61f5e8ffbeb2f6b373c967c80351333ee21
Author: Patrick Mooney <pmooney@pfmooney.com>
Date: 2020-04-01T15:22:43.000Z
12345 comm page should fallback to syscall after excessive migration
Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>
Reviewed by: Ryan Zezeski <rpz@joyent.com>
Reviewed by: Robert Mustacchi <rm@joyent.com>
Approved by: Dan McDonald <danmcd@joyent.com>