Then again, leaving Boinc to run at the default "nice 10" already grabs almost all of the CPU for an idle system. You can't use more CPU instruction cycles than exists, regardless of process priority!

Certain combinations of Linux, CUDA drivers and science apps (Just 2 examples: The PrimeGrid AP26 CUDA application and old versions of the Collatz CUDA app) ran significantly slower if the priority of the CUDA app was greater than 0. As soon as all CPU cores were under load (the CPU processes were running at the lowest priority) the GPU starving began and the performance dropped noticeably because the GPU was not fed fast enough. In some cases the runtimes more than doubled if the CUDA process wasn't reniced to 0.

Then again, leaving Boinc to run at the default "nice 10" already grabs almost all of the CPU for an idle system. You can't use more CPU instruction cycles than exists, regardless of process priority!

Certain combinations of Linux, CUDA drivers and science apps (Just 2 examples: The PrimeGrid AP26 CUDA application and old versions of the Collatz CUDA app) ran significantly slower if the priority of the CUDA app was greater than 0. As soon as all CPU cores were under load (the CPU processes were running at the lowest priority) the GPU starving began and the performance dropped noticeably because the GPU was not fed fast enough. In some cases the runtimes more than doubled if the CUDA process wasn't reniced to 0.

Yes, the CPU process latency problem for CUDA has been noticed for another example. Perhaps Boinc should automatically set a higher CPU priority for CUDA tasks?


Happy fast crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)