Please correct me if I'm wrong, but the ERR/OID structures only need locking because they are loaded dynamically ?.
Preload them all at startup with a global lock held, delete them at shutdown with a global lock held. If all the other access is 'read' the structures don't need a lock between times.
Might be something to consider putting on the "to do" list. I can understand things being done like that when memory was in short supply, but now, probably not so important.
Peter
[email protected] wrote: -----
To: [email protected]
From: Florian Weimer
Sent by: [email protected]
Date: 06/12/2014 06:23PM
Subject: Re: Locking inefficiency
From: Florian Weimer
Sent by: [email protected]
Date: 06/12/2014 06:23PM
Subject: Re: Locking inefficiency
On 06/11/2014 02:26 PM, Salz, Rich wrote:
>> What kinds of operations are protected by read locks?
>
> Looking at almost any of the global data structures, such as error tables, OID tables, and so on.
>
>> Often, RW locks aren't a win because maintaining just the read locks (without any writers) introduces contention at the hardware level, and parallelism does not increase all that much as a result. Paul McKenney's dissertation on RCU has some examples.
>
> We've monitored one of our applications, an SSL-terminating HTTP proxy server, under load. Of all the mutexes (futex, actually) in the system, the "error" lock is the most highly contended one. I'll see about posting some statistics.
Is this CRYPTO_LOCK_ERR? It would be interesting which locking path
actually triggers the contention. If it's the thread-local storage
re-implementation, it should be possible to use an ERR implementation
which uses native thread-local storage, which should be mostly
contention-free.
--
Florian Weimer / Red Hat Product Security Team
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
>> What kinds of operations are protected by read locks?
>
> Looking at almost any of the global data structures, such as error tables, OID tables, and so on.
>
>> Often, RW locks aren't a win because maintaining just the read locks (without any writers) introduces contention at the hardware level, and parallelism does not increase all that much as a result. Paul McKenney's dissertation on RCU has some examples.
>
> We've monitored one of our applications, an SSL-terminating HTTP proxy server, under load. Of all the mutexes (futex, actually) in the system, the "error" lock is the most highly contended one. I'll see about posting some statistics.
Is this CRYPTO_LOCK_ERR? It would be interesting which locking path
actually triggers the contention. If it's the thread-local storage
re-implementation, it should be possible to use an ERR implementation
which uses native thread-local storage, which should be mostly
contention-free.
--
Florian Weimer / Red Hat Product Security Team
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
