Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

ethcore/VerificationQueue don't spawn up extra worker-threads when explictly specified not to #9620

Merged
merged 3 commits into from Sep 26, 2018

Conversation

niklasad1
Copy link
Collaborator

@niklasad1 niklasad1 commented Sep 21, 2018

In the verification queue we spawn up maximum worker threads to do the work and don't honor if num-verifiers i.e, we still spawn the maximum number of threads which consume extra memory. Thus, this PR changes that!

However, there is one catch though when --scale-verifiers is specified then
we must spawn all the threads because all threads are created upon initialization AFAIK and eventually might be scaled (this could probably be fixed but out-of-scope for this PR)

OT:
In my opinion, it doesn't make sense to use both num-verifiers and
scale-verifiers they are kind of contradictory!

Examples how this works

See added test cases

@niklasad1 niklasad1 added A0-pleasereview 🤓 Pull request needs code review. F7-footprint 🐾 An enhancement to provide a smaller (system load, memory, network or disk) footprint. M4-core ⛓ Core client code / Rust. labels Sep 21, 2018
@5chdn 5chdn added this to the 2.2 milestone Sep 21, 2018
@5chdn 5chdn removed the F7-footprint 🐾 An enhancement to provide a smaller (system load, memory, network or disk) footprint. label Sep 21, 2018
cmp::min(cli_max_verifiers, cmp::min(num_cpus, MAX_VERIFIERS))
};

let state = Arc::new((Mutex::new(State::Work(cli_max_verifiers)), Condvar::new()));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be max_verifiers?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I actually meant is cli_max_verifiers should be <= max_verifiers

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to rework this logic cli_max_verifiers can be bigger than max_verifiers. I will add tests 🦀🦀

@niklasad1 niklasad1 added A3-inprogress ⏳ Pull request is in progress. No review needed at this stage. and removed A0-pleasereview 🤓 Pull request needs code review. labels Sep 21, 2018
@niklasad1 niklasad1 force-pushed the ethcore/VeriQueue-honor-cli-arg-num-workers branch 2 times, most recently from ce074ab to 1c6afc6 Compare September 21, 2018 20:14
@niklasad1 niklasad1 added A0-pleasereview 🤓 Pull request needs code review. and removed A3-inprogress ⏳ Pull request is in progress. No review needed at this stage. labels Sep 21, 2018
}

#[test]
fn worker_threads_specifyed_to_zero_should_set_to_one() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: s/specifyed/specified/

let spec = Spec::new_test();
let engine = spec.engine;
let mut config = Config::default();
config.verifier_settings.num_verifiers = 1;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be 0?

let engine = spec.engine;
let mut config = Config::default();
config.verifier_settings.num_verifiers = 5;
config.verifier_settings.scale_verifiers = true;
Copy link
Collaborator

@dvdplm dvdplm Sep 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add a helper to reduce the boiler plate code a bit, e.g.:

#[cfg(test)]
fn test_config(verifiers: usize, scale: bool) -> Config {
		let spec = Spec::new_test();
		let engine = spec.engine;
		let mut config = Config::default();
		config.verifier_settings.num_verifiers = verifiers;
		config.verifier_settings.scale_verifiers = scale;
        config
}

Copy link
Collaborator

@dvdplm dvdplm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor grumbles

let queue = BlockQueue::new(config, engine, IoChannel::disconnected(), true);
queue.scale_verifiers(8);

assert_eq!(queue.num_verifiers(), 8);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above: isn't this dependent on the test running with less than 9 cpus?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good question and the answer is yes. I coded this because we assume that the maximum number of CPUs is 8 by the constant MAX_VERIFIERS but I think it doesn't make sense when thinking about it now!

I will change this test and remove the constant!

In the verification queue we spawn up worker threads to do the work.
However, if `num-verifiers` is specified we still spawn the maximum
number of threads which consume extra memory.

There is one catch though when `--scale-verifiers` is specified then
we can't do it because all threads are created upon initilization AFAIK.

In my opinion, is doesn't to use both `num-verifiers` and
`scale-verifiers` they are kind of contradictory!
* Address grumbles in new tests
* Remove hardcoded `MAX_VERIFIERS` constant and replace it by relying
entirely on `num_cpu` crate instead inorder to support CPUs that have
more cores/logical cores
@niklasad1 niklasad1 force-pushed the ethcore/VeriQueue-honor-cli-arg-num-workers branch from a4312e4 to ab7d576 Compare September 25, 2018 21:46
@@ -39,9 +39,6 @@ pub mod kind;
const MIN_MEM_LIMIT: usize = 16384;
const MIN_QUEUE_LIMIT: usize = 512;

// maximum possible number of verification threads.
const MAX_VERIFIERS: usize = 8;
Copy link
Collaborator Author

@niklasad1 niklasad1 Sep 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is removed because it assumes max 8 CPUs now instead use on num_cpus::get()

fn worker_threads_scaling_with_specifed_num_of_workers() {
let num_cpus = ::num_cpus::get();
// only run the test with at least 2 CPUs
if num_cpus > 1 {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test is only useful on multicore CPUs

if num_cpus > 1 {
let spec = Spec::new_test();
let engine = spec.engine;
let config = get_test_config(num_cpus - 1, true);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can't overflow because num_cpus is at least 2

@ordian ordian added A8-looksgood 🦄 Pull request is reviewed well. and removed A0-pleasereview 🤓 Pull request needs code review. labels Sep 26, 2018
@5chdn 5chdn merged commit 3216b14 into master Sep 26, 2018
@5chdn 5chdn deleted the ethcore/VeriQueue-honor-cli-arg-num-workers branch September 26, 2018 14:11
dvdplm added a commit that referenced this pull request Sep 27, 2018
…mon-deps

* origin/master:
  ethereum libfuzzer integration small change (#9547)
  cli: remove reference to --no-ui in --unlock flag help (#9616)
  remove master from releasable branches (#9655)
  ethcore/VerificationQueue don't spawn up extra `worker-threads` when explictly specified not to (#9620)
  RPC: parity_getBlockReceipts (#9527)
  Remove unused dependencies (#9589)
  ignore key_server_cluster randomly failing tests (#9639)
  ethcore: handle vm exception when estimating gas (#9615)
  fix bad-block reporting no reason (#9638)
  Use static call and apparent value transfer for block reward contract code (#9603)
  HF in POA Sokol (2018-09-19) (#9607)
  bump smallvec to 0.6 in ethcore-light, ethstore and whisper (#9588)
  Add constantinople conf to EvmTestClient. (#9570)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A8-looksgood 🦄 Pull request is reviewed well. M4-core ⛓ Core client code / Rust.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants