Hi Mauricio, On Tue, Aug 15, 2023 at 10:20:50AM -0300, Mauricio Faria de Oliveira wrote: > Hey,
> I'd like to request input (initially thinking of involved teams: SRU, > Foundations) > on backports of some performance improvement patches to OpenSSL in Jammy. > (Please feel free to comment and include others as appropriate.) With my SRU Team hat on, I would be willing to consider such performance fixes in an SRU for jammy. Modern systems spend a lot of time in crypto routines, so performance certainly matters here! And while with glibc we have to worry about whether performance improvements for one chip are going to regress them for another, when we're talking about questions of whether hardware AES support is being exploited by openssl vs not (as I saw was the case for one of the referenced commits), it's a lot more straightforward. We also have a precedent of "hardware enablement" performance improvements on jammy for a number of server packages, to get them built with compiler options that significantly improve performance on particular arm64 server hardware. Caveat: I have not reviewed the actual commits that you are proposing to backport, I am only speaking for whether this is ok for SRU in principle. I would prefer to save a more in-depth review for the SRU unapproved queue. > SEG has a customer support ticket about it, which allows us to put in the > work, > but of course, it is OpenSSL, an SRU, thus agreement beforehand is needed. > ... > The context is OpenSSL 3.0 has known, significant performance regressions [0] > from OpenSSL 1.1.1, which has been addressed / still in-progress upstream: > 1) some patches in the 3.0 stable branch > 2) some patches in the master branch (ie, not backported to 3.0) > 3) some issues still open > > To offset regression risk, there are benefits; e.g., > 1) Performance: some improvement > 2) Security: smaller delta to 3.0 branch (may help with CVE fix backports) > 3) Community: possibly help with mentions of Ubuntu 22.04 in regressions > > IMHO, backports should be restricted to the 3.0 branch (so not to defeat 2). > > ... > > There are statements in this thread [1] that suggest we only backport bug > and security fixes, certainly understandable, but considering the numbers, > _perhaps_ we should consider it -- that's why I ask your opinion on this. > > For example, the test in bug [2]: > > 1) Focal, OpenSSL 1.1.1: 1.5 seconds > 2) Jammy, OpenSSL 3.0.2: 30 seconds (20x slower) > 3) Jammy, 7 cherrypicks: 5 seconds (3x slower) (PPA [3]) > > So, these 7 clean cherry-picks from 3.0 branch [4] help significantly, > for this customer's test-case, but we (SEG) would only analyze in more > detail (and possibly propose such changes) based on input from other > involved teams. (SRU, Foundations, and Security later.) > > Please let us know your thoughts. > > Thanks! > Mauricio > > [0] https://github.com/openssl/openssl/issues/17627#issuecomment-1060123659 > [1] > https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2023-May/019532.html > [2] https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544 > [3] https://launchpad.net/~mfo/+archive/ubuntu/lp2009544 > [4] https://github.com/openssl/openssl/pull/18151 > > -- > Mauricio Faria de Oliveira > > -- > Ubuntu-release mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ [email protected] [email protected]
signature.asc
Description: PGP signature
-- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
