Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Really love these kind of in depth investigations. However, I still want to know how windows manages to update the value in the shared memory so consistently without any impact to system performance.


https://blogs.msdn.microsoft.com/oldnewthing/20050902-00/?p=... rather implies it updates at the "tick" frequency, not actually every milisecond. Someone should do the followup test to see how frequently it actually changes.


Why would there be a system performance impact? This is just updating a memory value (that happens to be mapped into the VM of every process) at 2 kHz.


Silly me, the time is only updated once every half a millisecond. That's virtually zero CPU usage on a 2GHz chip.


It's worse than you might think. There are at least three things happening 2000x/second: getting an interrupt, writing shared memory, and returning. Getting a CPU interrupt takes something like 1k cycles. Dealing with the APIC may be even worse on a system without X2APIC, which is all too common due to crappy firmware (never benchmarked it, though), and returning takes many hundreds of cycles because x86 is very bad at these things. That shared memory write is n basically free unless NUMA is involved, and then it can be fairly bad.

So we're taking maybe 4M cycles per second used here. In practice, there's probably quite a bit of extra software overhead.


If it's part of a register map or can be computed from a register, you can just map that section of the registers into that 4k page and then use the function call to compute the return value without a context-switch. The hardware then becomes responsible for updating the value for you. The only thing you're left with is possible read latency, but that should be relatively small.

That's my theory.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: