New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop IO priority to idle while reading blocks for peer requests and startup verification #9245
base: master
Are you sure you want to change the base?
Conversation
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? |
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... |
Whenever I restart my node lately, I find myself eventually manually Added Mac and Windows support for completeness. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 6430b9232048666996d5d4c3ed154907e3daff67 (after adding missing #includes)
src/utilioprio.h
Outdated
#ifdef WIN32 | ||
bool ioprio_set_file_idle(FILE *); | ||
#else | ||
#define ioprio_set_file_idle(f) (false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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());
src/utilioprio.h
Outdated
#define IOPRIO_IDLER(actually_idle) ioprio_idler ioprio_idler_(actually_idle) | ||
|
||
#else | ||
#define ioprio_get() (-1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't seem like it should be necessary to declare these if the ioprio_idler
class isn't around to call them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
src/utilioprio.cpp
Outdated
// Distributed under the MIT software license, see the accompanying | ||
// file COPYING or http://www.opensource.org/licenses/mit-license.php. | ||
|
||
#ifdef HAVE_IOPRIO_SYSCALL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs #include "config/bitcoin-config.h"
to prevent link errors.
src/utilioprio.h
Outdated
// Distributed under the MIT software license, see the accompanying | ||
// file COPYING or http://www.opensource.org/licenses/mit-license.php. | ||
|
||
#ifndef BITCOIN_UTIL_IOPRIO_H |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should add #include "config/bitcoin-config.h"
Travis failure:
|
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... |
4060358
to
3b9eeae
Compare
I like this (concept ACK) although I wonder what the impact is on the p2p network as a whole if everyone ran this. |
There are win32 and win64 builds. Can't this just be enabled on the win64 build only? |
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.
Could be done, but it'd be confusing to couple those. The low-end systems running 32-bit versions would probably need this more. |
Rebased... |
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. |
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. |
@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. |
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. |
@TheBlueMatt That's exactly what this already does... priority is only dropped when serving peers, not when connecting blocks. |
@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. |
Before writing this, I generally ionice'd the entire bitcoind process to maintain system usability. |
Concept ACK. You need to mark the other ReadBlockFromDisks in net_processing low-priority as well. |
Concept ACK, but needs rebase. |
Needs rebase. |
Closing as this has needed rebase for more than 1 year. Feel free to reopen if you get a chance to work on this again in the future, thanks! |
Rebased |
Could you please add a description to the first comment? |
From CI:
|
Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft". |
Moving this to draft for now. Since re-opening (after being closed due to needing rebase for > a year), the request for a PR description hasn't been fullfilled, it's been failing to compile in the kernel CI, failing the tidy job, and has now been needing rebase again for nearly 2 months. Feel free to undraft when all 4 issues have been addressed. |
There hasn't been much activity lately and the patch still needs rebase. What is the status here?
|
No description provided.