Linux Patches Aim To Mitigate An Inconsistent Performance / NUMA Imbalancing Issue

[phoronix]

Phoronix: Linux Patches Aim To Mitigate An Inconsistent Performance / NUMA Imbalancing Issue

An interesting Linux kernel patch series was posted this week to address inconsistent NUMA imbalancing behavior for at least some workloads. In such cases these patches address performance differences seen over the past number of Linux kernel releases going on for a while...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Fix-Inconsistent-NUMA

[NotMine999]

Wow! Regression cases in features that span multiple Linux kernel versions.

f2581dfe042ea58a82804d8f2fd4cfad.jpg

Sounds like more thorough test cases need to be crafted by developers that really know the internals of this code. Yeah, that rules me out.

[Volta]

Wow! Regression cases in features that span multiple Linux kernel versions. Sounds like more thorough test cases need to be crafted by developers that really know the internals of this code. Yeah, that rules me out.

Yeah, because it's 'easy' to test every single workload. It's not a f****ing Quake and FPS drop.

[NotMine999]

Yeah, because it's 'easy' to test every single workload. It's not a f****ing Quake and FPS drop.

It's 'easy' to make snide comments when you have nothing better to offer.

For some sysadmins this issue could be important. I do know of some shops that value determinism in 'normal state' networking routing behaviors and application location (physical geography and then which server groups in a given DC) within their own networks. For them it serves as part of their overall baseline procedures, and how they determine 'when stuff isn't right'. For some out there that might all seem so [expletive]-retentive.

Sadly, the patch comments and the Phoronix article do not yield any insight into the history of this issue. Was it known in the past, but never addressed for whatever reason? Was it considered in the past, but written off with a "who would need/want that?" closing note? Is it really a new issue where some sysadmin really wants better determinism in this code?

I think the world of Linux kernel development periodically uncovers interesting (yet seemingly 'corner case' on first glance) problems in the process of code development on such a large scale. It might be an opportunity to fine-tune the development process and it's methodologies.

In closing, I think Linux developers need to spend a bit more time testing real-world use cases, not just the synthetic use cases, based on how endusers use (reasonable, but has to be converted to 'use cases') and-or expect (nebulous, much more difficult) Linux to behave, but sadly that sort of feedback process isn't what it could be and has never really developed beyond "dump an email to the Linux kernel developers mailing list and see if it sticks to someone on the list'.