-
Notifications
You must be signed in to change notification settings - Fork 1.7k
ethcore/VerificationQueue don't spawn up extra worker-threads when explictly specified not to
#9620
Conversation
| cmp::min(cli_max_verifiers, cmp::min(num_cpus, MAX_VERIFIERS)) | ||
| }; | ||
|
|
||
| let state = Arc::new((Mutex::new(State::Work(cli_max_verifiers)), Condvar::new())); |
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 this be max_verifiers?
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.
What I actually meant is cli_max_verifiers should be <= max_verifiers
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.
I need to rework this logic cli_max_verifiers can be bigger than max_verifiers. I will add tests 🦀🦀
ce074ab to
1c6afc6
Compare
| } | ||
|
|
||
| #[test] | ||
| fn worker_threads_specifyed_to_zero_should_set_to_one() { |
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.
typo: s/specifyed/specified/
| let spec = Spec::new_test(); | ||
| let engine = spec.engine; | ||
| let mut config = Config::default(); | ||
| config.verifier_settings.num_verifiers = 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.
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; |
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 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
}
dvdplm
left a comment
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.
minor grumbles
| let queue = BlockQueue::new(config, engine, IoChannel::disconnected(), true); | ||
| queue.scale_verifiers(8); | ||
|
|
||
| assert_eq!(queue.num_verifiers(), 8); |
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.
Same comment as above: isn't this dependent on the test running with less than 9 cpus?
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.
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
a4312e4 to
ab7d576
Compare
| const MIN_QUEUE_LIMIT: usize = 512; | ||
|
|
||
| // maximum possible number of verification threads. | ||
| const MAX_VERIFIERS: usize = 8; |
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.
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 { |
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.
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); |
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.
This can't overflow because num_cpus is at least 2
…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)
In the verification queue we spawn up maximum worker threads to do the work and don't honor if
num-verifiersi.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-verifiersis specified thenwe 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-verifiersandscale-verifiersthey are kind of contradictory!Examples how this works
See added test cases