Intel continues with more optimizations to the Linux kernel
phoronix.com
phoronix.com
> Wangyang and Arjan reported a bottleneck in the networking code related to struct dst_entry::__refcnt. Performance tanks massively when concurrency on a dst_entry increases.
> This happens when there are a large amount of connections to or from the same IP address. The memtier benchmark when run on the same host as memcached amplifies this massively. But even over real network connections this issue can be observed at an obviously smaller scale (due to the network bandwith limitations in my setup, i.e. 1Gb).
Basically, processes that produce a lot of threads (i.e.: 100+) suffer performance degradation. This impacted network performance by up to 5% on 1 Gb/s connections and showed up to 3.2x performance degradation in synthetic benchmarks.
Independent testing verifies these improvements in the Memcached benchmark. Simulating a more realistic workload using Cockroach DB shows a more modest performance improvement of ~5% in terms of ops/s.
Maybe we could just stop tracking references to these dst_entry. This way there would be no contention when tracking reference counts. So no performance loss. Some would no longer be used, but hey RAM is cheap. And to cleanup memory we'd scan the memory for these references from time to time. Probably beginning by the only way (transitive) references can occur from their roots: the thread stacks. We'd quickly pause threads, scan their stack, unpause them while ordering them to notify us if they would write new content to memory. We'd do that at the compiler level so this can be general to all memory management. This way we'd have a concurrent scanning. We could also copy memory as we scan it, removing the gaps and compacting it for better CPU cache usage. But that would require a memory ordering model, threading, and compiler behavior to go hand-in-hand. We'd call it an abstract machine, dare I say virtual? This system would help us automatically collect these memory objects that have become garbage...
Yeah, no. Not a chance.
Are they specifically looking at places where they have a disadvantage or a potential advantage relative to ARM etc?
So, yeah, ARM etc reminds them that there are alternatives. They don't need to focus on specific comparisons with ARM for it to be good business to keep Linux running as well as they can make it on Intel. Plus the marketing from being seen to do it.
It seems pretty straightforward to me. Focusing only on spending money on very specific measurable outcomes on your bottom line, while it might be all the rage these days, can be pretty self-defeating in the long-term. Big companies generally know this, and can afford it.
The article at https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/ is an excellent introduction if you want to know more.
This mainly happened because the idle power consumption without any power staging has improved drastically and so has the power density of batteries.
So this isn’t really on Intel also sleep and various other power states aren’t used in servers.
Two problems I have encountered are 1) Locking too big an area (i.e. holding a mutex over an entire function when you just have to protect a single line of code) and 2) spinning off too many threads. I check the hardware to know how many physical cores the CPU has before deciding how many threads to create.
Spinning off hundreds of threads when the CPU only can run 8 at a time often does not help and can even be counter-productive.
Depends on how many of those threads become blocked by I/O.
If you spin 200 threads, but 192 of them are blocked by I/O (waiting for disk and/or ethernet), then those 8-remaining threads effectively use the 8-cores of your CPU.
Old-school programmers would remember the days of 1-core CPUs, where you'd need to use a threads (or processes actually) to effectively utilize hard drives or your ethernet connections.
Even with Disk I/O, too many threads trying to read/write to a HDD at once can lead to performance problems as the heads are thrashing trying to access different parts of the disk.
Too many programmers just spin off threads without understanding what the implications really are.