Run miner threads at priority SCHED_IDLE (see sched(7))

[ppetr]

This way miners can fully utilize all spare CPU power without affecting performance of the rest of the system.

[jtgrassie]

Why the change? Miners likely want mining to be at full-throttle, not at a lowered priority. There's also already the feature (built-in) to mine when idle (that's cross-platform).

[ppetr]

I'm aware of the feature, but I believe it's sub-optimal: The background mining feature sort of mimics running a thread at an idle priority, but by nature it's always a crude approximation.

• When the load average is above --bg-mining-idle-threshold, the system can have spare CPU resources, but the background miner thread remains stopped.
• It reacts to the system's state only slowly based on --bg-mining-min-idle-interval. Which can be bad both ways - it can under-utilize available CPU power, or negatively affect other processes' performance (like when running on a desktop machine).

So running a thread at an idle priority seems to me to be better in multiple aspects: It lets the system to utilize full CPU power available, lets the system react immediately to the CPU demand, and it's simpler to implement.

If you prefer, I can add a new feature flag for this that'd complement the existing background mining feature.

[jtgrassie]

but I believe it's sub-optimal

I don't disagree the current solution is sub-optimal, but it is 1) cross-platform and 2) surely impacts your changes anyway.

If you prefer, I can add a new feature flag for this that'd complement the existing background mining feature.

I think that's probably a better approach. Though a user can already simply ignore the --bg-mining-* options (i.e. not ask for bg mining in the start_mining command), and launch monerod with nice. But if you can make your changes work across all platforms, and it's an option instead of (or complimenting) the existing approach, I suppose that's more desirable (as it only affects the mining threads).

[jtgrassie]

Probably needs to be something like:

auto thread = boost::thread(attrs, std::forward<Callable>(func));
auto handle = thread.native_handle();
SetThreadPriority(handle, THREAD_PRIORITY_LOWEST); 

(THREAD_MODE_BACKGROUND_BEGIN only works for the current thread according to the docs).

[ppetr]

a user can already simply ignore the --bg-mining-* options (i.e. not ask for bg mining in the start_mining command), and launch monerod with nice.

I thought of this option too, but apparently that's problematic because it also prevents the main daemon from progressing as it should (https://monero.stackexchange.com/a/13983/16159).

OK, I'll try to adapt it to all platforms and add an appropriate flag.

[ppetr]

THREAD_MODE_BACKGROUND_BEGIN only works for the current thread according to the docs

Yes, I noticed that, and this was why I designed the function so that creates a thread, so that it can execute code within.

PTAL?

[jtgrassie]

Minor gripe, but formatting should follow the rest of the file (here, braces on newlines).

[jtgrassie]

Same, follow rest of file style

[jtgrassie]

Yes, I noticed that, and this was why I designed the function so that creates a thread, so that it can execute code within.

I can't speak to whether how you've now done it for Windows works or not (I presume you've tested), but just using THREAD_PRIORITY_LOWEST should suffice, and then launching in the same way as the non-windows version. I suppose if the way you've implemented works fine though, it may be better...

[ppetr]

Thank you for the review. Hmm, one test is failing, IDK why, I'll need to figure this out.

(I'll be unavailable for some time so please be patient with me, I'll get back to this once I'm back.)

[ppetr]

I can't speak to whether how you've now done it for Windows works or not (I presume you've tested), but just using THREAD_PRIORITY_LOWEST should suffice, and then launching in the same way as the non-windows version. I suppose if the way you've implemented works fine though, it may be better...

Yes, tested, this approach seems to works quite nicely. According to the docs using THREAD_MODE_BACKGROUND_BEGIN should ensure that

the system lowers the resource scheduling priorities of the thread so that it can perform background work without significantly affecting activity in the foreground.

I'll fix the formatting and also I still need to figure out why one of the tests is broken.