Over the course of the Corosync's code base lifetime, we have gone from single thread unix socket IPC to multithreaded shared memory IPC. This has introduced a degree of complexity which makes understanding the flow of the Corosync daemon difficult to understand.
The reason this change has occurred over this time period is focused around providing higher performance. As Moore's law states, we see a doubling of transistor count roughly every 13 months. However, the march towards higher clock speeds has more or less stopped approximately 5 years ago. Silicon vendors have "hit the wall" on clock speed using current design technology. To do something with those transistors, CPU manufacturers have instead focused on producing multiple cores in one cpu die, and I expect this trend to continue without much additional clock speed improvement far into the future. As a result of this change in CPU vendor focus, Corosync adopted a multithreaded design to burn up more CPU cycles on our high performance data paths (specifically cpg_mcast_joined api). This has resulted in a significant complication of the code base to deal with the multiple threads for some high performance workloads. What is worse is all of those cpu clock cycles are usually being burned up in memcpy which is limited by the memory bandwidth of the system. I have created the cpgol branch to experiment with an idea raised by Angus and Dave. The essence of the idea is "what if we don't need IPC to go really fast because of cpg_mcast_joined?". This opens up all sorts of possibilities for simplification by removing nearly all threads in the corosync daemon except our logging thread which cannot operate in blocking mode. The purpose of the experiment is to determine if we can offload the transmit and receive operations of the CPG API to the client application, thus eliminating the need to transfer all those message contents over IPC. As a result, the requirement that ipc perform at high levels would be gone from Corosync. The net result is simplification of the Corosync daemon into a nearly single thread process. This is targeted as 3.0 material. Regards -steve _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
