24-core CPU and I can’t type an email – part two
randomascii.wordpress.com
24-core CPU and I can’t type an email – part two
1–10 of 101 posts
Re: 24-core CPU and I can’t type an email – part two
#2I wonder how much cpu time has been liberated through the CFG scan patch.
Re: 24-core CPU and I can’t type an email – part two
#3What exactly did his it department do using wmi to query this Win32_PerfFormattedData_PerfProc_ProcessAddressSpace_Costly? I can't find this in the article
Re: 24-core CPU and I can’t type an email – part two
#4Congratulations on your article, as well.
Re: 24-core CPU and I can’t type an email – part two
#5> the lock was being acquired and released ~49,000 times and was held for, on average, less than one ms at a time. But for some reason, even though the lock was released 49,000 times the Chrome process was never able to acquire it.
Well, locking is hard.
> The good news is that even though there is occasional unfairness, there is unlikely to be persistent unfairness. In order for a thread to steal the lock, it needs to hit the tiny window where the lock is available. In practice, a thread is unlikely to be this lucky repeatedly.
https://blogs.msdn.microsoft.com/oldnewthing/20170705-00/?p=...
> The fact is, any time anybody makes up a new locking mechanism, THEY ALWAYS GET IT WRONG. Don't do it. Take heed. You got it wrong. Admit it. Locking is _hard_.
Re: 24-core CPU and I can’t type an email – part two
#6> the lock was being acquired and released ~49,000 times and was held for, on average, less than one ms at a time. But for some reason, even though the lock was released 49,000 times the Chrome process was never able to acquire it. Well, locking is hard. > The good news is that even though there is occasional unfairness, there is unlikely to be persistent unfairness. In order for a thread to steal the lock, it needs…
Actually this is exactly because someone in Windows used the plain old mutex. I'd call that "your granddad's lock". It's old, crotchety, unfair and shouldn't be used in situations where any concurrency can be expected.
This despite the kernel having a nice RCU mechanism inside as well as waitfree queues.
Re: 24-core CPU and I can’t type an email – part two
#7What exactly did his it department do using wmi to query this Win32_PerfFormattedData_PerfProc_ProcessAddressSpace_Costly? I can't find this in the article
> "By the way, the reason that the hangs kept happening at 10:30 am is just because that’s when our IT team ran their inventory scans. If you want to trigger a scan manually, you can go to Control Panel | Configuration Manager | Actions | Select ‘Hardware Inventory Cycle’ and then Run Now."
Re: 24-core CPU and I can’t type an email – part two
#8Re: 24-core CPU and I can’t type an email – part two
#9> the lock was being acquired and released ~49,000 times and was held for, on average, less than one ms at a time. But for some reason, even though the lock was released 49,000 times the Chrome process was never able to acquire it. Well, locking is hard. > The good news is that even though there is occasional unfairness, there is unlikely to be persistent unfairness. In order for a thread to steal the lock, it needs…
Actually this is exactly because someone in Windows used the plain old mutex. I'd call that "your granddad's lock". It's old, crotchety, unfair and shouldn't be used in situations where any concurrency can be expected. This despite the kernel having a nice RCU mechanism inside as well as waitfree queues.
If there was a spinlock, the problem stay.
> the rule simply is that you MUST NOT release and immediately re-acquire the same spinlock on the same core, because as far as other cores are concerned, that's basically the same as never releasing it in the first place.
https://yarchive.net/comp/linux/spinlocks.html
Other mechanisms do exist of course.
Re: 24-core CPU and I can’t type an email – part two
#10I have on my desk a machine that would be an equivalent of a large datacenter two decades ago and then sometimes it is barely able to keep up with me pressing keys on the keyboard.
I think the next major step will be for the humanity to learn make software more efficient and effective rather than throw more CPU cycles at the problem.