Drop IO priority to idle while reading blocks for getblock requests

[luke-jr]

No description provided.

[laanwj]

Please move this to a new include file util_ioprio.h.

[laanwj]

Concept ACK. Though not very happy to introduce platform-specific voodoo - we only just got rid of thread priority manipulation. But it may be worth the hassle, I don't know.

Can we quantify whether this works or not somehow?

[gmaxwell]

This will also delay other processing, in particular block relay-- at least until the handling is made more concurrent-- no? Not a reason to not do it, but maybe a reason to not do it by default for everyone.

I second the need to quantify this-- I could imagine it making for a big usability improvement. ... or not mattering at all. If the former, I want it... if the latter...

[luke-jr]

Whenever I restart my node lately, I find myself eventually manually ioniceing the entire process as it slows down other things monitoring it in iotop. I can't be sure it's sending out old blocks, but I can't imagine what else it'd be spending so much time reading... :/

Added Mac and Windows support for completeness.

[ryanofsky]

ACK 6430b92 (after adding missing #includes)

[ryanofsky]

Needs #include "config/bitcoin-config.h" to prevent link errors.

[ryanofsky]

Should add #include "config/bitcoin-config.h"

[ryanofsky]

It doesn't seem like it should be necessary to declare these if the ioprio_idler class isn't around to call them.

[luke-jr]

We can simplify some of the other stuff (move the logic into the class itself) if low-level access is undesired, but for now it's too early to know if these won't be needed IMO.

[ryanofsky]

Maybe change this to ((void)false) to prevent a compiler warning:

main.cpp:1673:12: warning: statement has no effect [-Wunused-value]
     ioprio_set_file_idle(filein.Get());

[fanquake]

Travis failure:

'../../src/'`utilioprio.cpp
In file included from ../../src/utilioprio.cpp:9:0:
../../src/utilioprio.h: In destructor ‘ioprio_idler::~ioprio_idler()’:
../../src/utilioprio.h:42:51: error: ‘LogPrintf’ was not declared in this scope
             LogPrintf("failed to restore ioprio\n");

[luke-jr]

Looks like to make the Windows part work, we need to bump _WIN32_WINNT to 0x0600 which means it will only run on Vista or newer. AFAIK this is okay(?), but I'm going to leave it for a separate PR...

[rebroad]

I like this (concept ACK) although I wonder what the impact is on the p2p network as a whole if everyone ran this.

[martinschwarz]

Looks like to make the Windows part work, we need to bump _WIN32_WINNT to 0x0600 which means it will only run on Vista or newer.

There are win32 and win64 builds. Can't this just be enabled on the win64 build only?

[laanwj]

Looks like to make the Windows part work, we need to bump _WIN32_WINNT to 0x0600 which means it will only run on Vista or newer. AFAIK this is okay(?), but I'm going to leave it for a separate PR...

Isn't Vista the version after Windows XP? As we dropped support for Windows XP in 0.13, it seems that requiring Vista for 0.15 is fine.

There are win32 and win64 builds. Can't this just be enabled on the win64 build only?

Could be done, but it'd be confusing to couple those. The low-end systems running 32-bit versions would probably need this more.

[luke-jr]

Rebased...

[TheBlueMatt]

Hmm, I dont think this is really the best idea as long as our message processing is still single-threaded. Really we need to refactor stuff so that block reading is async and the network processing can continue for other peers while we're serving blocks for peers in IBD, otherwise we may block receiving a new block longer than required.

[luke-jr]

That's somewhat independent from this issue. If users need to shut off their node to use their computer, the delay for processing a new block will be even longer.

[ryanofsky]

@TheBlueMatt @luke-jr, maybe a compromise would be to make this behavior configurable, and perhaps to default to dropping priority if user is running bitcoin-qt on a desktop.

[TheBlueMatt]

Another approach which might be simpler would be to have the validation.h-exposed versions of ReadBlockFromDisk drop io priority so that net_processing will use low priority when answering remote-node queries but connecting blocks will not. With 0.15 I/O when doing initial sync is somewhat better, so this may also be less of an issue now unless the user is running with -peerbloomfilters.

[luke-jr]

@TheBlueMatt That's exactly what this already does... priority is only dropped when serving peers, not when connecting blocks.

[TheBlueMatt]

@luke-jr I was referring to the possibility of not exposing a priority flag in validation.h's API - that seems a bit overkill IMO, as evidenced by the fact that there are now two ReadBlockFromDisk calls in net_processing which dont get the low-priority flag :p. Though that would also result in RPC ReadBlockFromDisk calls getting de-prioritized.

More importantly, I'm curious how much we need this anymore - it seems most of the complaints about I/O usage were primarily due to 0.13.1 preferential peering...On systems where your I/O is severely limited, I both don't know how much this will help (in my experience Linux' ionice is mostly worthless when it comes to desktop latency) and don't know if its not better to direct people towards maxuploadtarget or peerbloomfilters so as to avoid simply slowing down your peers because your I/O is too slow.

[luke-jr]

Before writing this, I generally ionice'd the entire bitcoind process to maintain system usability.

[TheBlueMatt]

Concept ACK. You need to mark the other ReadBlockFromDisks in net_processing low-priority as well.