Tweet
There is something most people would not even consider that is the case that is.
The Amdahl's law problem on atomic operations is nightmare effects on performance when you hit it.
What is the problem with open read close on really small sysfs/procfs even with syscalls there is almost zero time between the open and the close. This result in not enough time for the ulimit or other atomic operations to propagate between the MMUs and cpu caches in your larger core count systems.
Single threaded event being forced due to doing atomic operations faster than propagation speed in fact results in worst case Amdahl's law and its worse than most people would think. People are not think of the MMU as a core so the MMU is progressing forwards while the CPU/instruction call processors are basically halted.
Yes atomic operations allowing locking and so on to be off loaded to the MMU generally does give performance gains due to the CPU being able to use other threads while propagation is under way. Problem there are a few corner cases where the instead of providing advantage it gives you major performance headaches. Remember the MMUs and cache systems also have a upper limit on how many atomic operations they can deal with in a particular time frame before again stall.
Yes simpler 1 to 2 thread CPUs don't have this problem in a big way because the propagation if atomic state is simple. More cores more threads the simpler it is to stall the system with excessive atomic operations. Yes stall being making the system have the performance of 0Hz processor for time frames can bad enough that a 8088 4Mhz processor performing the same task will win against a epyc 128 core because 8088 4Mhz single core and not getting stuck in atomic operation sync problem.
Readfile syscall is about 1 reducing syscalls. 2 reducing/removing atomic operations that can happen faster than the replication rate MMU that can result in stalling the CPUs in large core count systems at effectively 0Hz processing speed. The second part is the big thing.
The worst kind is the double operation atomic. You have changed X atomic value you now have to wait on the sync before you can change it again. See the problem with open read close being really fast. open ulimit change may go fine but you get to close before ulimit atomic change from open has propagated you are now running into trouble out of order operations can cover this a limited amount. Best way to fix this problem remove the open and close operations and remove the atomic value change because its a add and subtract of 1 resulting in a zero value change in the end.
The most likely times to out run the means to propagate atomic values fast enough is on system start up and system shutdown. The most file open and close of a application happens to be in startup and shutdown of applications as well. The most atomic protected values changes for process tracking and so on again happen in startup and shutdown.
Yes this problem does effect how fast CPU cores can clock up in the boot process. There are issues with increasing usage multi core systems. Amdahl's law gives us maths to calculate the problems of multi core systems but it does require correct application of the maths to understand how the problems will display self. Locating the single thread problems can be quite tricky particularly thinking advanced cpu/mmu design has hidden single thread logic that does come back and bite.
The Amdahl's law problem on atomic operations is nightmare effects on performance when you hit it.
What is the problem with open read close on really small sysfs/procfs even with syscalls there is almost zero time between the open and the close. This result in not enough time for the ulimit or other atomic operations to propagate between the MMUs and cpu caches in your larger core count systems.
Single threaded event being forced due to doing atomic operations faster than propagation speed in fact results in worst case Amdahl's law and its worse than most people would think. People are not think of the MMU as a core so the MMU is progressing forwards while the CPU/instruction call processors are basically halted.
Yes atomic operations allowing locking and so on to be off loaded to the MMU generally does give performance gains due to the CPU being able to use other threads while propagation is under way. Problem there are a few corner cases where the instead of providing advantage it gives you major performance headaches. Remember the MMUs and cache systems also have a upper limit on how many atomic operations they can deal with in a particular time frame before again stall.
Yes simpler 1 to 2 thread CPUs don't have this problem in a big way because the propagation if atomic state is simple. More cores more threads the simpler it is to stall the system with excessive atomic operations. Yes stall being making the system have the performance of 0Hz processor for time frames can bad enough that a 8088 4Mhz processor performing the same task will win against a epyc 128 core because 8088 4Mhz single core and not getting stuck in atomic operation sync problem.
Readfile syscall is about 1 reducing syscalls. 2 reducing/removing atomic operations that can happen faster than the replication rate MMU that can result in stalling the CPUs in large core count systems at effectively 0Hz processing speed. The second part is the big thing.
The worst kind is the double operation atomic. You have changed X atomic value you now have to wait on the sync before you can change it again. See the problem with open read close being really fast. open ulimit change may go fine but you get to close before ulimit atomic change from open has propagated you are now running into trouble out of order operations can cover this a limited amount. Best way to fix this problem remove the open and close operations and remove the atomic value change because its a add and subtract of 1 resulting in a zero value change in the end.
The most likely times to out run the means to propagate atomic values fast enough is on system start up and system shutdown. The most file open and close of a application happens to be in startup and shutdown of applications as well. The most atomic protected values changes for process tracking and so on again happen in startup and shutdown.
Yes this problem does effect how fast CPU cores can clock up in the boot process. There are issues with increasing usage multi core systems. Amdahl's law gives us maths to calculate the problems of multi core systems but it does require correct application of the maths to understand how the problems will display self. Locating the single thread problems can be quite tricky particularly thinking advanced cpu/mmu design has hidden single thread logic that does come back and bite.
Comment