RFC on Jammy SRU with OpenSSL 3.0 backports for performance
Rafael Lopez
rafael.lopez at canonical.com
Fri Sep 1 00:50:29 UTC 2023
Hi Adrien,
I added some results to LP#2009544 for your consideration, including tests
on mantic and lunar.
I also tested a couple of good-looking patches in addition to PR#18151 [1].
Summary below, see LP for detailed results and PPAs with patches.
PR#18151 + PR#17881 [2] - up to ~2x improvement over [1]
PR#18151 + PR#17921 [3] - up to ~2.5x improvement over [1]
PR#18151 + PR#17881 [2] + PR#17921 [3] - up to ~4x improvement over [1]
(based on user CPU time)
PR#17921 [3] might be a good candidate to SRU in addition to [1] at some
stage. It is a moderate change in Jammy as there are a number of
pre-requisite patches including refactoring. However, all said
pre-requisites are merged into 3.0 branch upstream and already included in
both Lunar and Mantic (you can cleanly cherry pick PR#17921 for those). The
performance increase is noticeable. [3] itself is not merged to 3.0
upstream even though the pre-reqs are, see [4] for a comment on this. Seems
to fit what you described regarding upstream (not) backporting performance
patches into 3.0. It is merged into 3.1.
PR#17881 [2] also brings noticeable improvement, though less, and has
nearly all the pre-reqs in 3.0 (and mantic/lunar). Looks like one [5] is
missing which was not backported to the 3.0 branch, though it is in 3.1.
I haven't analysed the patches in any detail, wanted to see if they were
worth the effort performance wise first.
Rafael
[1] https://github.com/openssl/openssl/pull/18151
[2] https://github.com/openssl/openssl/pull/17881
[3] https://github.com/openssl/openssl/pull/17921
[4] https://github.com/openssl/openssl/pull/20421#issuecomment-1457743122
[5] https://github.com/openssl/openssl/pull/6127
On Wed, Aug 30, 2023 at 6:36 AM Adrien Nader <adrien at notk.org> wrote:
> Hi,
>
> On Mon, Aug 28, 2023, Adrien Nader wrote:
> > 1- SRU with select patches
> >
> > There have been a number of issues reported with upstream patches but
> > they had low impact and/or had easy workarounds. Since there are now
> > other incentives to do an SRU, I plan to include everything in it.
> > I think all patches are in Lunar or even previous releases.
> >
> > I don't have a list for performance patches however, except for a couple
> > ones. I don't plan to list them by myself; instead I welcome inputs on
> > that. Benchmarking is simply too much work, especially considering the
> > kind of performance regressions from 1.1 to 3.0 that I've seen talked
> > about on the openssl bug tracker. That would probably be a year-long
> > full-time job.
> >
> > I would like to start preparing this SRU soon and I hope to have it
> > ready in October (that's my first SRU this large but I think/hope that's
> > realistic). Since it would be the first one, I plan to stick to changes
> > that don't require backporting work. For subsequent SRUs we could
> > include more patches as Simon said (i.e. patches from master provided
> > they go into non-LTS releases first during their development cycle).
>
> My list of patches so far for the SRU can be seen at this address:
>
> https://bugs.launchpad.net/ubuntu/jammy/+source/openssl
>
> It's likely that the list will be frozen before the end of next weeek.
>
> There's only one thing I'd like to also SRU and which is about removing
> dead code that also unecessarily sources debconf in the postinst and
> which tends to trigger the infamous bug with thousands of duplicates on
> launchpad. Unfortunately I'm not sure I can do that without delaying
> this SRU and I might have to leave it for a subsequent one.
>
> --
> Adrien
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20230901/2ba076ae/attachment.html>
More information about the Ubuntu-release
mailing list