What is the best way to reduce system-call overhead while reading the files in the pseudo filesystem e.g. hwom ?
I'd start with "not caring"; at 1 ms periods, that overhead is measurable¹, but not critical. That overhead is on the order of 1–4 µs on modern systems, so less than a single percent of your period.
Don't believe me? I coded this benchmark; you can compile it with g++ -O2 -lfmt -std=c++20 -o shortreads shortreads.cc and then run it as ./shortreads /sys/class/hwmon/hwmon{whatever is your CPU sensor}/temp1_input.
I get a pretty consistent
1933ns per read()
67125
last output
1933 ns is not close to the order of 1 ms. So, chill and use your POSIX API ;) 73% of the CPU time on my machine for that million read temperature values is spent in pci_conf1_read and another 15% in pci_conf1_write. My temperature sensor read speed is hence limited almost exclusively by the speed at which my CPU can issue small PCI transfers.
What is the best way of reading sensor data in general?
Stick to the kernel API: read the pseudofile.
And what is the best way for reading out the cpu frequency specifically?
see above.
Speaking of whatever you want to do: Have you verified these thermal sensors are even this fast? Physically, it makes very little sense to sense temperature in a solid this often. Heat diffusion isn't instant, instead it's governed by the Heat equation (a differential equation that takes properties of the material into account and tells you how, given a current thermal distribution and heat sources and sinks, things will look an infinitesimally small timestep in the future); you will, quite likely, be massively oversampling the actual speed of things, to no additional information gain.
Also note that due to this thermal "slowness", any sensible semiconductor thermal sensor design will be designed for an integration period that's not very fast; you're essentially sensing quantum noise there, and you will want to do that for a while to get a good estimate of the actual resulting observables (probably, a voltage, but things do get complicated in practice).
Using hwmon this could be possible for the temperature data.
Many sensors in the hwmon subsystem are I²C/PMBUS sensors. You will not have a great time hammering a 100 kHz I²C bus with 1 kHz of requests to the sensor. So, "could be possible" comes with a question mark there, atop of the physical constraints!
That's probably not the case for your CPU (unless it's really old); for example, all modern AMD CPUs have a PCI devices that you read the die, ctl, and ccd temperatures from; that happens each time you read the device file.
¹
You need data from the kernel there. To the best of my knowledge, none of these sensors are actual memory mapped devices that autonomously change values in a memory region when that is read, or DMA capable, so you need to query them through the kernel space – you can't even let a root userland process have the memory view of the device, because there's no such memory view.
So, this is down to reducing overheads in a read/ioctl interface. Depending on what that driver subsystem supports, there might be io_uring methods of coalescing multiple requests to reduce overhead, but that won't help you – you want to read these sensors multiple times, individually spaced. You will need at least one syscall per read if you do it from user land, I don't see any ways around that.
(You could write whatever you want to do with these values as a kernel module. But then you just shifted your problem elsewhere, made everything more complicated AND dangerous AND harder to develop AND need root privileges.)
