[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: Tumblr_l_87305344721433.png (1.1 MB, 846x1200)
1.1 MB PNG
previous: >>108820540

#define __NR_clock_settime            227
#define __NR_clock_gettime 228
#define __NR_clock_getres 229

https://man7.org/linux/man-pages/man2/clock_settime.2.html

tl;dr:
manage system clocks

in yesterday's thread, i mentioned these clock syscalls. i thought we'd already discussed them, but apparently not. i guess i was confusing them with some of the nanosleep syscalls.

overall, a pretty boring set of syscalls, though their functionality is rather important. i guess the most interesting aspect is probably the dynamic clockfd based off of character devices. i'd never heard of that before! i can't imagine why you'd want to bother, but it's cool that you can!

relevant resources:
man man

man syscalls

https://man7.org/linux/man-pages/
https://linux.die.net/man/
https://elixir.bootlin.com/linux/
https://elixir.bootlin.com/musl/
https://elixir.bootlin.com/glibc/
>>
>i thought we'd already discussed them
Same. I could have sworn I'd seen these in a previous thread.
>>
>>108828786
we had a get/set timeofday
why that needs a separate syscall, i can't even begin to imagine
>>
>no mentioning of vDSOs
Shite thread.
>>
>>108828810
i'd brought it up the last thread, so i was worried mentioning it again would feel repetitive
>>
>>108828820
You're kidding, right?
>not part of the vdso
OK, so now that it is ...
>>
>>108829445
well the vdso is interesting enough but like it's basically just caching executable code (not really but close enough)
>>
>>108828752
clock_gettime is my favorite syscall. I use it (through the vDSO ofc) constanly
>>
>>108833313
what do you like about it?
>>
if you run PTP on your system, it will create a /dev/ptp0 device file.
You can open it, convert the file descriptor to clock ID and use it with clock_gettime. A bit of an obscure interface indeed.
See the Dynamic clocks chapter of a manpage.

#define CLOCKFD 3
#define FD_TO_CLOCKID(fd) ((~(clockid_t) (fd) << 3) | CLOCKFD)
#define CLOCKID_TO_FD(clk) ((unsigned int) ~((clk) >> 3))

int fd = open("/dev/ptp0", O_RDWR);
clockid_t clkid = FD_TO_CLOCKID(fd);
struct timespec ts;
clock_gettime(clkid, &ts);

for some reason the manpage has a bug and uses struct timeval type with clock_gettime????????
>>
>>108834817
lol
>>
>>108834665
It's easy to use, incredibly fast, and precise enough to time individual functions. It's extremely useful for microbenchmarking.
>>
>>108836638
I think RDTSC (or whatever equivalent exists on your architecture) would do you much more of a service. At least it doesn't require a fucking vDSO.
>>
>>108834817
/*
* Bit fields within a clockid:
*
* The most significant 29 bits hold either a pid or a file descriptor.
*
* Bit 2 indicates whether a cpu clock refers to a thread or a process.
*
* Bits 1 and 0 give the type: PROF=0, VIRT=1, SCHED=2, or FD=3.
*
* A clockid is invalid if bits 2, 1, and 0 are all set.
*/

I don't think many people know this and it's very poorly documented, but you can also get CPU time for any process or thread through these clock_gettime.
#include <time.h>
#include <unistd.h>
#include <stdio.h>

int main() {
//pid_t pid = getpid();
pid_t pid = 1;
clockid_t clk = ((~pid) << 3) | 2;
struct timespec t;
clock_gettime(clk, &t);

printf("cputime for pid 1: %f\n", t.tv_sec + 1e-9 * t.tv_nsec);

return 0;
}

>>108836861
Some arches don't have it, and the vDSO overhead is incredibly low. clock_gettime(CLOCK_MONOTONIC) usually takes less than 60ns, and it's even better if you do the vDSO directly instead of the glibc wrapper.
>>
>>108836954
On my system, it results in:
cputime for pid 1: 1.890482

The interfaces for getting CPU time in /proc only go down to hundredths of a second, which is why htop counts CPU utilization in increments of 0.7% by default (refresh interval is 1.5s). If it used clock_gettime instead, it could be much more precise.
>>
>>108836998
9 hours later, and it's gone up a tiny bit. init really doesn't do much.
cputime for pid 1: 2.181636
>>
>>108828752
is this used in managing processes (multithreading?), or is it just time?
>>
>>108839496
No, usually the kernel sets up hardware interrupts to enable preemption. Those obviously don't know anything about syscalls.
>>
>>108839496
You can see how much CPU time an individual thread or process has used with these syscalls as in >>108836954, but actually creating threads/processes are done with fork or clone3.



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.