Linux 6.1 Will Try To Print The CPU Core Where A Seg Fault Occurs

[stormcrow]

Yes, I know the reasons. But unless a core is really bad, and a process segfaults as soon as it lands on it, there is the potential to mis-identify? As corruption may not be immediately evident but require further operations? That was pretty much my only point, although I wasn't really clear with how I expressed it.

Ah understood.

[Paradigm Shifter]

While I won't venture an opinion on the wisdom of locking threads to cores in any particular case, the reason threads and processes "bounce between" cores when the CPU isn't saturated is IO load/cache/thermal balancing, not because of some wacky indeterminate weirdness. Also far more likely to happen going forward is moving processes between performance/efficiency cores (for Intel/ARM systems - AMD manages that internally).

Yes, I know the reasons. But unless a core is really bad, and a process segfaults as soon as it lands on it, there is the potential to mis-identify? As corruption may not be immediately evident but require further operations? That was pretty much my only point, although I wasn't really clear with how I expressed it.

[stormcrow]

So is it easier to lock processes to specific cores? If I watch CPU utilisation for loads which only partially load a system, the usage bounces between cores at an astonishing rate unless I faff around locking individual threads to individual cores.

While I won't venture an opinion on the wisdom of locking threads to cores in any particular case, the reason threads and processes "bounce between" cores when the CPU isn't saturated is IO load/cache/thermal balancing, not because of some wacky indeterminate weirdness. Also far more likely to happen going forward is moving processes between performance/efficiency cores (for Intel/ARM systems - AMD manages that internally).

[Paradigm Shifter]

So is it easier to lock processes to specific cores? If I watch CPU utilisation for loads which only partially load a system, the usage bounces between cores at an astonishing rate unless I faff around locking individual threads to individual cores.

[stormcrow]

What a strange idea, I thought segfaults were just normal C behaviour.

Well written C programs shouldn't segfault. Frequent faults usually points to hardware failure. Bad RAM is the most common problem in my experience followed by storage devices going bad, then roughly on par with each other are PSU & motherboard failure (often because the one kills the other). I rarely have hit a bad CPU that didn't just completely fail (once in 30 years), but in large systems pinpointing a failed or failing CPU is probably a fairly acute problem if you have hundreds or thousands of physical packages with tens of cores on each package.

Edit to add: For my personal systems in the past 10 years or so I've had 3 GPU failures (two AMD one Nvidia), 2 separate instances of bad RAM modules, three PSUs & motherboards dying (it's what broke me of ever buying Gigabyte boards ever again, the other was an inherited ThinkServer), and 4 mechanical hard drive failures. Interestingly enough no CPU or SSD failures.

The usual indicator of hardware failure is programs start crashing (segfaults or the equivalent) if there's not an outright failure to POST/boot.

[Mahboi]

What a strange idea, I thought segfaults were just normal C behaviour.

[phoronix]

Phoronix: Linux 6.1 Will Try To Print The CPU Core Where A Seg Fault Occurs

A change now merged for Linux 6.1 will attempt to print the CPU core where a segmentation fault happens. The hope by printing the CPU/core where a segmentation fault happens is that over time trends may materialize with this information potentially being useful for helping to spot faulty CPUs...

https://www.phoronix.com/news/Linux-6.1-Seg-Fault-Print-CPU