<div dir="ltr">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] <a href="https://github.com/openssl/openssl/pull/18151">https://github.com/openssl/openssl/pull/18151</a> [2] <a href="https://github.com/openssl/openssl/pull/17881">https://github.com/openssl/openssl/pull/17881</a> [3] <a href="https://github.com/openssl/openssl/pull/17921">https://github.com/openssl/openssl/pull/17921</a> [4] <a href="https://github.com/openssl/openssl/pull/20421#issuecomment-1457743122">https://github.com/openssl/openssl/pull/20421#issuecomment-1457743122</a> [5] <a href="https://github.com/openssl/openssl/pull/6127">https://github.com/openssl/openssl/pull/6127</a> <div> </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 30, 2023 at 6:36 AM Adrien Nader <<a href="mailto:adrien@notk.org">adrien@notk.org</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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: <a href="https://bugs.launchpad.net/ubuntu/jammy/+source/openssl" rel="noreferrer" target="_blank">https://bugs.launchpad.net/ubuntu/jammy/+source/openssl</a> 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 </blockquote></div>