- Joined
- Jul 23, 2011
- Messages
- 54
- Motherboard
- Supermicro X11DAi-N
- CPU
- 2x 8260M
- Graphics
- Radeon VII
- Mac
- Classic Mac
- Mobile Phone
I am very pleased to report....
Total success! I found the piece of the puzzle, and it effects all multiprocessor systems and I am fairly confident that this will solve the strange hangs, freezes, and performance issues that users like @analogo have been suffering.
It's nothing to do with the C612.
It's the dual processors. There is the different xnu power management scheme in the kernel that is specifically for multiprocessor systems.
First, some back story: I'd since corrected any issues with power management, injected frequency vectors, corrected the SSDTs using information I got booted in linux and had all my frequencies correct. So I knew this wasn't anything to do with using an engineering sample.
My poor scores had a very strange behavior to them. My scores would be fairly high right after a restart, usually 60,000 thereabouts, but would quickly drop over minutes down to my low 44000 score. If I immediately ran Geekbench a second time, I would usually get 50,000 or 48,000, and a third run would net 44-45,000, and that is where it would stay. However, a quick reboot would reset this, and it would happen all over again.
At first I thought this was a heat issue and the CPUs were rapidly heating once OS X was loaded due to some issue in the power management. However, I verified that my cooling (which is very generous for 2x 135W) wasn't an issue. I did some stress tests in Linux while monitoring all core temperatures, and even with all cores at 3GHz for 10 minutes straight, I couldn't even hit 50°C on a single core. So my cooling certainly seemed adequate.
I was reading through some of Piker-Alpha's posts about xnu power management, and something caught my eye: he had a list of flags, from which only -xcpm was the only one given any attention. There were some debug flags, some cstate/idlestate tweaking things, but a very important flag was over looked.
-xcpm_ipi
I am an electrical engineer, do a lot of embedded stuff, and IPI was a term I was familiar with. inter-processor interrupts. They let one CPU force another CPU to drop whatever it is doing, and do something else. Any single CPU system wouldn't even have these, and I imagine using -xcpm_ipi would cause a kernel panic or simply not work on those systems.
But, on multiprocessor systems, IPIs are used by Apple for something critical in power management of all those cores. Indeed, considering Xeons have a unified cache and there are some considerations that must be made about which cores can be clocked how and when, depending on which things are accessing what in one cache or another, I can see how one might employ IPIs in some sort of central role. The fact that the performance is fixed by a reboot, then quickly degrades, makes me think it is some sort of cache or memory issue, and flushing it with a reboot temporarily fixes the problem. I haven't actually looked into it, and I won't bore you with this technical stuff anymore.
If you have a Haswell-EP or Broadwell-EP multiprocessor hackintosh, remove -xcpm from your boot arguments in clover, and add instead -xcpm_ipi
It will make your system buttery smooth and well behaved. And it increased my performance almost half again. At least compared to 45,000. Only, these scores are permanent, they don't go away. It's really that easy. One kernel flag was the problem the entire time.
Here are my new, consistent scores with -xcpm_ipi turned on:
I now have native xcpm working, complete with all the weird extra (C10 anyone?) Broadwell C-States, in my case, 21 P-States, and single and multicore turboboost working flawlessly. On the Broadwell-EP platform, with dual CPUs.
Total success! I found the piece of the puzzle, and it effects all multiprocessor systems and I am fairly confident that this will solve the strange hangs, freezes, and performance issues that users like @analogo have been suffering.
It's nothing to do with the C612.
It's the dual processors. There is the different xnu power management scheme in the kernel that is specifically for multiprocessor systems.
First, some back story: I'd since corrected any issues with power management, injected frequency vectors, corrected the SSDTs using information I got booted in linux and had all my frequencies correct. So I knew this wasn't anything to do with using an engineering sample.
My poor scores had a very strange behavior to them. My scores would be fairly high right after a restart, usually 60,000 thereabouts, but would quickly drop over minutes down to my low 44000 score. If I immediately ran Geekbench a second time, I would usually get 50,000 or 48,000, and a third run would net 44-45,000, and that is where it would stay. However, a quick reboot would reset this, and it would happen all over again.
At first I thought this was a heat issue and the CPUs were rapidly heating once OS X was loaded due to some issue in the power management. However, I verified that my cooling (which is very generous for 2x 135W) wasn't an issue. I did some stress tests in Linux while monitoring all core temperatures, and even with all cores at 3GHz for 10 minutes straight, I couldn't even hit 50°C on a single core. So my cooling certainly seemed adequate.
I was reading through some of Piker-Alpha's posts about xnu power management, and something caught my eye: he had a list of flags, from which only -xcpm was the only one given any attention. There were some debug flags, some cstate/idlestate tweaking things, but a very important flag was over looked.
-xcpm_ipi
I am an electrical engineer, do a lot of embedded stuff, and IPI was a term I was familiar with. inter-processor interrupts. They let one CPU force another CPU to drop whatever it is doing, and do something else. Any single CPU system wouldn't even have these, and I imagine using -xcpm_ipi would cause a kernel panic or simply not work on those systems.
But, on multiprocessor systems, IPIs are used by Apple for something critical in power management of all those cores. Indeed, considering Xeons have a unified cache and there are some considerations that must be made about which cores can be clocked how and when, depending on which things are accessing what in one cache or another, I can see how one might employ IPIs in some sort of central role. The fact that the performance is fixed by a reboot, then quickly degrades, makes me think it is some sort of cache or memory issue, and flushing it with a reboot temporarily fixes the problem. I haven't actually looked into it, and I won't bore you with this technical stuff anymore.
If you have a Haswell-EP or Broadwell-EP multiprocessor hackintosh, remove -xcpm from your boot arguments in clover, and add instead -xcpm_ipi
It will make your system buttery smooth and well behaved. And it increased my performance almost half again. At least compared to 45,000. Only, these scores are permanent, they don't go away. It's really that easy. One kernel flag was the problem the entire time.
Here are my new, consistent scores with -xcpm_ipi turned on:
I now have native xcpm working, complete with all the weird extra (C10 anyone?) Broadwell C-States, in my case, 21 P-States, and single and multicore turboboost working flawlessly. On the Broadwell-EP platform, with dual CPUs.