Just to close the loop, the patch for this has been applied. Thanks.
On Mon, May 5, 2014 at 7:25 PM, Daniel Sands <[email protected]> wrote: > We applied the patch and got some improvement, but there is still a bit > of trouble. Here are the timing values for a stripped-down version of > the code: > > Before (all calls start at the same time): > Called PingCore in 0.076844 seconds (0) pid 20829 > Called PingCore in 0.130758 seconds (0) pid 20830 > Called PingCore in 0.161245 seconds (0) pid 20834 > Called PingCore in 0.160294 seconds (0) pid 20832 > <snip>... > Called PingCore in 0.185752 seconds (0) pid 20839 > Called PingCore in 0.362372 seconds (0) pid 20843 > Called PingCore in 0.379132 seconds (0) pid 20846 > > After (all calls start at the same time): > <snip>... > Called PingCore in 0.225353 seconds (0) pid 7063 > Called PingCore in 0.238172 seconds (0) pid 7062 > Called PingCore in 0.254867 seconds (0) pid 7059 > Called PingCore in 0.262224 seconds (0) pid 7069 > Called PingCore in 0.273392 seconds (0) pid 7067 > Called PingCore in 0.284404 seconds (0) pid 7061 > > Omitting the call entirely, we get: > <snip>... > Called PingCore in 0.114693 seconds (0) pid 6503 > Called PingCore in 0.109111 seconds (0) pid 6504 > Called PingCore in 0.118763 seconds (0) pid 6512 > Called PingCore in 0.111967 seconds (0) pid 6513 > Called PingCore in 0.111785 seconds (0) pid 6505 > > > And in the full system we still see: > Called PingCore in 0.451584 seconds (0) pid 9519 > Called PingCore in 0.583949 seconds (0) pid 9517 > Called PingCore in 0.703487 seconds (0) pid 9531 > Called PingCore in 0.842056 seconds (0) pid 9516 > Called PingCore in 0.919599 seconds (0) pid 9530 > <snip>... > Called PingCore in 1.757831 seconds (0) pid 9528 > Called PingCore in 1.779220 seconds (0) pid 9535 > Called PingCore in 1.848178 seconds (0) pid 9526 > > So we still have another bottleneck to track down. Will report on this > when it becomes apparent. > > One potential suggestion might be to add an API that initializes the > montgomery context without a lock, and let the client worry about the > locking semantics. Since we always use a separate DH context for each > connection, this would be a huge help. Still another option might be > to initialize the Mont context at DH_new time since I see no standard > way to tell the system not to use this method, so it must now be > established as *the* way to calculate values. > > Anyway, I can say that the patch did help. > > On Mon, 2014-05-05 at 13:16 -0400, Geoffrey Thorpe wrote: > > Hi Daniel, > > > > > > Great. I already posted a patch to openssl-dev, it's at; > > http://marc.info/?l=openssl-dev&m=139923556631116&w=2 > > > > > > If you want to apply it ("git apply" or "git am") directly, the raw > > email patch can be downloaded using; > > http://marc.info/?l=openssl-dev&m=139923556631116&q=raw > > > > > > > > Thanks in advance for any feedback on this. > > > > > > > > Cheers, > > Geoff > > > > > > > > > > On Mon, May 5, 2014 at 1:07 PM, Daniel Sands <[email protected]> > > wrote: > > I'm using the RHEL6 standard distro. I can certainly test a > > patch for > > you. > > > > On Sat, 2014-05-03 at 00:01 -0400, Geoffrey Thorpe wrote: > > > I hadn't noticed this serialisation before, thanks. I'll try > > to send a > > > patch over the weekend some time, in case you're able to > > test? If so, > > > what version (or git branch) are you using? > > > > > > > > > Cheers, > > > Geoff > > > > > > > > > > > > > > > On Fri, May 2, 2014 at 6:54 PM, Daniel Sands > > <[email protected]> > > > wrote: > > > Examining performance bottlenecks on a busy server, > > we > > > discovered that > > > connections are being forced to serialize due to > > calls to > > > DH_generate_key. I looked through the source, and > > if I > > > understand it > > > correctly, the code locks a common DH mutex when it > > uses > > > Montgomery > > > Multiplication, and due to the way it sets a flag, > > it always > > > does. > > > > > > But I have not yet found any reason why this > > requires critical > > > section > > > protection. I do not see any global variables that > > are being > > > manipulated by the call, nor any resource > > contention. Is it > > > possible > > > that the mutex lock is a holdover from earlier > > code? Could > > > this locking > > > behavior be removed? > > > > > > > > > > > > ______________________________________________________________________ > > > OpenSSL Project > > > http://www.openssl.org > > > Development Mailing List > > > [email protected] > > > Automated List Manager > > > [email protected] > > > > > > > > > > > > > > > > ______________________________________________________________________ > > OpenSSL Project > > http://www.openssl.org > > Development Mailing List > > [email protected] > > Automated List Manager > > [email protected] > > > > > > > > > > >
