Mesa's Disk Cache Code Now Better Caters To 4+ Core Systems

[phoronix]

Phoronix: Mesa's Disk Cache Code Now Better Caters To 4+ Core Systems

Most Linux gamers these days should be running at least quad-core systems so Mesa 19.3 has been updated to reflect that reality with the number of CPU threads used by their disk cache...

http://www.phoronix.com/scan.php?pag...ache-Quad-Core

[ssokolow]

The threads are set to minimum priority so for those not running at least quad-core processors the negative impact is hopefully minimal.

I'm curious why they don't just query the number of CPU cores and set the number of threads accordingly. It can't be that complicated if Python makes it as simple as multiprocessing.cpu_count().

[geearf]

I'm curious why they don't just query the number of CPU cores and set the number of threads accordingly. It can't be that complicated if Python makes it as simple as multiprocessing.cpu_count().

Yeah that would definitely make sense.

[tarceri]

Anything more than 4 threads is likely not to help much and just overkill.

[MastaG]

Then it should query and not set anything bigger than 4.

[ssokolow]

Anything more than 4 threads is likely not to help much and just overkill.

I'm on a dual-core PC which predates AMD's introduction of the PSP. I was wondering why they don't do the equivalent of this Python pseudocode:

if multiprocessing.cpu_count() >= 4:
    set_threads(4)
else:
    set_threads(1)

[tarceri]

I'm on a dual-core PC which predates AMD's introduction of the PSP. I was wondering why they don't do the equivalent of this Python

The extra threads will not hurt performance as the lowest priority flag is set. There is no need to introduce extra code and make things more complicated.

[x_wing]

I'm on a dual-core PC which predates AMD's introduction of the PSP. I was wondering why they don't do the equivalent of this Python pseudocode:

if multiprocessing.cpu_count() >= 4:
set_threads(4)
else:
set_threads(1)

multiprocessing is a Python package that is shipped by default with the interpreter (AFAIK). As we're talking of C code, I think that the only option here is to parse /proc/cpuinfo, but that is probably not portable.

[ssokolow]

The extra threads will not hurt performance as the lowest priority flag is set. There is no need to introduce extra code and make things more complicated.

To be honest, that sounds like an extreme case of premature optimization and being penny-wise and pound-foolish, given that it's apparently as simple as adding #include <sys/sysinfo.h> followed by calling get_nprocs() while, even at lowest priority, spawning more threads still has potential to cause unexpected effects when dealing with a CPU scheduler operating on the system as a whole.

[schmidtbag]

Holy crap people give it a rest. It's really not a big deal. We're only talking a few threads here. If you're really that worried, chances are you already have crappy performance to begin with.