Skip to content
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

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

luke-jr
Copy link
Member

@luke-jr luke-jr commented Nov 30, 2016

No description provided.

src/util.h Outdated Show resolved Hide resolved
@laanwj
Copy link
Member

laanwj commented Nov 30, 2016

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
Copy link
Contributor

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
Copy link
Member Author

luke-jr commented Nov 30, 2016

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.

Copy link
Contributor

@ryanofsky ryanofsky left a 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)
Copy link
Contributor

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)
Copy link
Contributor

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.

Copy link
Member Author

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.

// Distributed under the MIT software license, see the accompanying
// file COPYING or http://www.opensource.org/licenses/mit-license.php.

#ifdef HAVE_IOPRIO_SYSCALL
Copy link
Contributor

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
Copy link
Contributor

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"

@fanquake
Copy link
Member

fanquake commented Dec 1, 2016

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
Copy link
Member Author

luke-jr commented Dec 1, 2016

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...

@luke-jr luke-jr force-pushed the ionice branch 2 times, most recently from 4060358 to 3b9eeae Compare December 2, 2016 04:08
@rebroad
Copy link
Contributor

rebroad commented Dec 19, 2016

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

@martinschwarz
Copy link

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
Copy link
Member

laanwj commented Mar 13, 2017

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
Copy link
Member Author

luke-jr commented Aug 21, 2017

Rebased...

@TheBlueMatt
Copy link
Contributor

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
Copy link
Member Author

luke-jr commented Aug 21, 2017

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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Member Author

luke-jr commented Nov 11, 2017

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

@TheBlueMatt
Copy link
Contributor

@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
Copy link
Member Author

luke-jr commented Nov 11, 2017

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

@TheBlueMatt
Copy link
Contributor

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

@sipa
Copy link
Member

sipa commented Mar 6, 2018

Concept ACK, but needs rebase.

@kristapsk
Copy link
Contributor

Needs rebase.

@davidgumberg
Copy link
Contributor

@luke-jr

I have rebased this here.

Feel free to take this.

@glozow
Copy link
Member

glozow commented Sep 26, 2022

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!

@luke-jr
Copy link
Member Author

luke-jr commented Sep 26, 2022

Rebased

@Xekyo
Copy link
Contributor

Xekyo commented Oct 12, 2022

Could you please add a description to the first comment?

@MarcoFalke
Copy link
Member

MarcoFalke commented Oct 19, 2022

From CI:

./.libs/libbitcoinkernel.so: undefined reference to `ioprio_set_idle()'

@DrahtBot
Copy link
Contributor

🐙 This pull request conflicts with the target branch and needs rebase.

Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".

@fanquake
Copy link
Member

fanquake commented Dec 6, 2022

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.

@fanquake fanquake marked this pull request as draft December 6, 2022 10:40
@DrahtBot
Copy link
Contributor

DrahtBot commented Mar 6, 2023

There hasn't been much activity lately and the patch still needs rebase. What is the status here?

  • Is it still relevant? ➡️ Please solve the conflicts to make it ready for review and to ensure the CI passes.
  • Is it no longer relevant? ➡️ Please close.
  • Did the author lose interest or time to work on this? ➡️ Please close it and mark it 'Up for grabs' with the label, so that it can be picked up in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet