Am Montag, 25. April 2016, 12:35:32 schrieb Andi Kleen: Hi Andi,
> > > > If it is the latter, can you explain where the scalability issue comes > > > > in? > > > > > > A single pool which is locked/written to does not scale. Larger systems > > > need multiple pools > > > > That would imply that even when you have a system with 1000 CPUs, you want > > to have a large amount of random numbers. Is this the use case? > > That is right. Large systems do more work than small systems. > If the system is for example handling SSL connections it needs > more random numbers to handle more connections. > > BTW the problems happen long before 1000 CPUs, more like 12-18 cores > competing. > > Also today's large system is tomorrow's small systems. The > systems affected are actually not that large anymore. > > The original numbers > > Without patchkit: > > 1 node: 1x > 2 nodes: 0.75x > 3 nodes: 0.55x > 4 nodes: 0.42x I have changed the LRNG now such that a multiple instantiation of the secondary DRBG can be implemented with very limited amount of code. Thus, the proposal you have for the nonblocking_pool can be adapted. Yet I have not implemented such duplication as I first would like to see whether the initial proposal of my LRNG is considered acceptable. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
