OS-5804: lxbrand needs support for CLOCK_*_CPUTIME_ID timers

Details

Issue Type:Bug
Priority:3 - Elevated
Status:Need More Info
Created at:2016-11-17T21:50:56.000Z
Updated at:2021-10-06T19:14:55.035Z

People

Created by:Former user
Reported by:Former user
Assigned to:Dan McDonald

Related Issues

Labels

lxbrand

Description

In additional to the clock_gettime functionality referencing CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID, it also permits timers to be created against those clocks. Certain software such as mapr demands the ability to at least create such timers. Presently our emulation wrongly maps mapr's request to CLOCK_REALTIME, which seems to appease it for now. Eventually, we'll need something that resembles timer functionality for those clocks.

Comments

Comment by Dan McDonald
Created at 2020-02-18T18:53:45.209Z
Updated at 2020-02-24T16:14:42.128Z

There are two distinct approaches:

1.) The "-2" clockid used by mapr, via older versions of glibc/alternatives works today on LX, but, per the report, maps to CLOCK_REALTIME. One could argue it should map to CLOCK_HIGHRES anyway.  Regardless, the actual values of CLOCK_{THREAD,PROCESS}_CPUTIME_ID still map to errors for timer_create(), while -2 does not.  One could make the actual two values map to an existing, native supported clockid (e.g. CLOCK_HIGHRES) for those purposes, deceptive as it might be. This is a quick and dirty fix.

2.) Proper timer functionality for these clocks should be done by implementing clock backends.  There seems to be existing itimer support for both process and thread CPUTIME, but they are seemingly hardwired into setitimer(2) semantics w.r.t. hardwired signal delivery, etc. etc.  A solution of this sort would require months for study, design, and bringup.


Comment by Former user
Created at 2020-02-26T15:43:54.639Z

Per discussion in mattermost:

OS-5804 is under evaluation for option 1. Was hoping to confirm it isn't completely stupid today.
... Yeah, push it out 2weeks, even though I'm planning to have it back NLT COB Friday.

Removing dependency on TRITON-2058, adding to OS-8101.


Comment by Dan McDonald
Created at 2020-02-27T14:56:58.904Z

Attached test program t2.c.  On regular Linux it works.  On LX before this fix it fails.  On LX after this fix, it succeeds, but behaves like CLOCK_MONOTONIC was used.

Regular Linux (note CPU time consistency):

centos(~/SWSUP-1563)[0]% ./t2
4 secs elapsed.
4 secs elapsed.
4 secs elapsed.
4 secs elapsed.
Got SIGALRM, compute_count now at start = 5, end = 4
4 secs elapsed.
4 secs elapsed.
4 secs elapsed.
4 secs elapsed.
4 secs elapsed.
Got SIGALRM, compute_count now at start = 10, end = 9
5 secs elapsed.
4 secs elapsed.
4 secs elapsed.
4 secs elapsed.
4 secs elapsed.
Got SIGALRM, compute_count now at start = 15, end = 14
4 secs elapsed.
4 secs elapsed.
4 secs elapsed.
4 secs elapsed.
4 secs elapsed.

LX with fix (note more realtime-like behavior):

f02da1ad-841c-c9c9-f587-f9f2f5819cac:~# ./t2
7 secs elapsed.
Got SIGALRM, compute_count now at start = 2, end = 1
7 secs elapsed.
7 secs elapsed.
Got SIGALRM, compute_count now at start = 3, end = 3
7 secs elapsed.
Got SIGALRM, compute_count now at start = 5, end = 4
7 secs elapsed.
7 secs elapsed.
Got SIGALRM, compute_count now at start = 6, end = 6

Comment by Dan McDonald
Created at 2020-02-27T22:02:29.701Z

Updated t2.c to allow parameterization to show how the CPUTIME clocks {mis}behave under LX.


Comment by Dan McDonald
Created at 2021-05-26T23:51:16.151Z

Option 1, described above, has a simple patch:  https://kebe.com/~danmcd/webrevs/OS-5804-quick-and-dirty/

Option 2, as also described above, is FAR more complicated, and will likely require months of work.


Comment by Dan McDonald
Created at 2021-10-06T18:42:40.509Z

illumos 14126 is creating the back-ends.  It's part of building Option 2.


Comment by Dan McDonald
Created at 2021-10-06T19:14:55.035Z

https://www.illumos.org/issues/14140 is the next part of Option 2.  Once that's done, we can allow the LX layer(s) to directly access the native versions.