RFC on Jammy SRU with OpenSSL 3.0 backports for performance
Rafael Lopez
rafael.lopez at canonical.com
Fri Sep 15 02:13:49 UTC 2023
Hi Adrien,
Thanks for working on the SRU. FWIW, I tested the packages from your PPA,
looks good to me and results match previous tests performed.
Let me know if I can do any further testing or assist in any way to
expedite the SRU.
Regards,
Rafael
On Sat, Sep 9, 2023 at 1:50 AM Adrien Nader <adrien at notk.org> wrote:
> Hi Rafael,
>
> On Fri, Sep 01, 2023, Rafael Lopez wrote:
> > 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
>
> Thanks a lot for digging into this.
>
> I thought a bit about the best way forward and I came up with three or
> four big steps:
>
> 1- SRU [1] to Jammy in addition to bugfixes
> 2- Include [2] and [3] in the next Ubuntu release (also next LTS)
> Per policy these cannot go straight into an SRU I think. Moreover
> there are a lot of patches already for Jammy which can make resolving
> conflict more difficult and error-prone, and while [3] from
> openssl-3.1 applies almost completely cleanly, [2] doesn't.
> 3- After OO is released, SRU [2] and [3] to Jammy
> 4- Bonus: SRU the same version as OO to Jammy (_maybe_ it will make more
> sense to skip step 3 but I can't predict it)
>
> Unfortunately we have to wait until the OO release for [2] and [3].
>
> I've created a PPA for step 1 at
> https://launchpad.net/~adrien-n/+archive/ubuntu/openssl-jammy-sru . It
> should be ready besides last-minute debian/changelog fixes (trimming an
> entry and removing ~ppa*, and triple-checking the version number).
>
> I need to trigger as many autopkgtests in the PPA as I can fit, which is
> something I intend to do this evening and/or over the week-end but I'm
> pretty confident.
>
> --
> Adrien
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20230915/b12e32ac/attachment.html>
More information about the Ubuntu-release
mailing list