> On Sep 30, 2026, at 5:07 PM, Christian Schulte <[email protected]> wrote:
> Am 30.09.2026 um 22:14 schrieb Stuart Henderson:
>>> On 2026-09-30, Christian Schulte <[email protected]> wrote:
>>> Am 30.09.2026 um 18:32 schrieb H. Hartzer:
>>>> I think this is largely a hardware support thing and you'll have a range
>>>> of supported speeds. Like you might have 800MHz, 1200MHz, 1800MHz, and
>>>> finally 2200MHz.
>>> It is. I failed to find a way to program the hardware clock generators
>>> in any way to accomplish this. It's like soldering a different quartz
>>> onto the PCB. I understand that.
>>> Maybe I need to explain what made me ask for this. Timeouts used by e.g.
>>> cnd_timedwait or pthreads_cond_timedwait and functions like those
>>> internally use CLOCK_REALTIME or CLOCK_MONOTONIC. The issue with this is
>>> that those clocks advance "in hardware". It can well happen that the
>>> scheduler never provided any compute to a thread waiting on some
>>> condition so that the condition may well time out, although the waiting
>>> thread never got scheduled in between - so to say. I am having a hard
>>> time setting up some environment I can use to reliable test this.
>>
>> not entirely reliable, but maybe run some stress processes (in ports;
>> e.g. in malloc mode might be good) or just a bunch of md5 -tttt to try
>> to starve it of cpu?
>
> It's not about starving the CPU. That would be easy. It's about
> functions taking e.g. a struct timespec to specify some absolute timeout
> value using a "hardware" definition of what is a second and what is a
> nanosecond completely independent of what the scheduler "thinks" is a
> second or a nanosecond. There is no way to specify relative timeouts,
> though. I am a bit lost here, I admit.
I am curious what you are trying to do. You want to simulate a scenario where
a process requests a timeout at cycle 0 and then at cycle 10 it is woken up by
that timeout, but never anywhere between cycles 1-9 did it ever get a time
slice… (“cycle” here has no actual meaning, obviously it doesn’t represent
anything like ticks, Hz, etc. just using it as a counter of “time” passing).
Are you attempting to exploit a vulnerability or at least prove it’s possible?
Are you just being super duper thorough and want to test your own program for
extreme edge cases? Are you debugging a crashed program and want to reproduce
what you think might have happened? Or it must be something else…
Normally when trying to test such extreme edge cases, one would build an
abstraction. Abstract away the timeout stuff and then when you are trying to
test, you use a simulation implementation. I’m not sure how that would be done
for your desired goal, perhaps a modified kernel? Add a sysctl to register
with the scheduler that you do not want to be scheduled until some future time
or event? Obviously it is entirely designed just for your intended test.
Sounds a lot like sleep :)
Thanks for explaining, I am super curious.
-Brian
