Apologies for the tardy response to this thread, freeze deadlines and PTO has prevented me from responding sooner.
On Mon, Jan 15, 2024 at 12:14 PM Roberto Bartzen Acosta <roberto.aco...@luizalabs.com> wrote: > > > > Em qua., 10 de jan. de 2024 às 15:37, Ilya Maximets <i.maxim...@redhat.com> > escreveu: > > > > On 1/9/24 13:53, Simon Horman wrote: > > > On Mon, Jan 08, 2024 at 08:34:36AM -0300, Roberto Bartzen Acosta via dev > > > wrote: > > >> Current version of debian/rules simply uses the default lto GCC > > >> optimization settings during the linkage process. > > >> > > >> The main problem with this approach is that GCC on OS like Ubuntu > > >> Jammy, for example, can enable the -flto=auto option during the > > >> openvswitch building and linking process. In this case, the linked > > >> dynamic libraries would need to be builded based on the same lto > > >> optimization options, at the risk of not working, according to > > >> documentation [1]. The documentation also says: "When producing the final binary, GCC only applies link-time optimizations to those files that contain bytecode. Therefore, you can mix and match object files and libraries with GIMPLE bytecodes and final object code. GCC automatically selects which files to optimize in LTO mode and which files to link without further processing." Which to me reads like it is supported to mix LTO optimized and non-optimized objects? > > >> > > >> I'm not sure of the real benefits of using this link-time optimization > > > > At least for DPDK-enabled builds LTO usually provides noticeable > > performance improvement. In the past I measured up to 10% packet > > rate increase with LTO. Though the gap went a bit lower with modern > > compilers. I think, it should still provide noticeable performance > > improvements at least for the userspace datapath. > > > > >> option, and since when it is enabled it causes problems with shared > > >> libs link libjemalloc, for example, it seems safer overwritten > > >> compiler decision by passing -fno-lto command. > > > > Building shared libraries with LTO is indeed a bit problematic. > > I agree that correctness should have a priority over potential > > performance benefits. > > > > Just out of curiosity, how do you add jemalloc into dependencies? > > Using one of the environment variables? > > yeap, I'm just using the standard libs flag on a Ubuntu OS as suggested by > the OpenvSwitch documentation (LIBS=-ljemalloc ) [1] > > override_dh_auto_configure: > test -d _debian || mkdir _debian > cd _debian && ( \ > test -e Makefile || \ > ../configure --prefix=/usr --localstatedir=/var --enable-ssl LIBS=-ljemalloc \ > --sysconfdir=/etc \ > $(DATAPATH_CONFIGURE_OPTS) \ > $(EXTRA_CONFIGURE_OPTS) \ > ) > > > [1] https://docs.openvswitch.org/en/latest/intro/install/general/ This made me scratch my head, because in recent development efforts I found the need to rebuild a package linking OVS to libunwind, which is not the default for the package. And this worked fine, despite having the default Ubuntu LTO settings applied. Furthermore both the libunwind and libjemalloc packages appear to be built with the default LTO settings as well. > > > > >> > > >> [1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto > > >> > > >> Reported-at: > > >> https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2015748 > > >> Signed-off-by: Roberto Bartzen Acosta <rbart...@gmail.com> > > > > > > Hi, > > > > > > for one reason or another our automation was unable to apply this patch. > > > But I have done so locally in my own tree (it is not upstream) > > > and run the GitHub based tests with success: > > > > > > https://github.com/horms/ovs/actions/runs/7448358289 > > > > > > From my point of view this patch seems reasonable. > > > > > > Acked-by: Simon Horman <ho...@ovn.org> > > > > > > But I would be interested to hear feedback from others before applying it > > > to the upstream tree. > > > > @Frode, do you have any thoughts on this change? Is it a problem > > also for the main (in-distribution) Ubuntu/Debian builds? TBH, I'm not convinced the LTO configuration is the root of the issue, and I'd prefer if we left the LTO options alone and figured out what's really going on here. -- Frode Nordahl > > > > > >> --- > > >> debian/rules | 2 +- > > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > >> > > >> diff --git a/debian/rules b/debian/rules > > >> index dc5cc8a65..de8771813 100755 > > >> --- a/debian/rules > > >> +++ b/debian/rules > > >> @@ -2,7 +2,7 @@ > > >> # -*- makefile -*- > > >> #export DH_VERBOSE=1 > > >> export DEB_BUILD_MAINT_OPTIONS = hardening=+all > > >> -export DEB_CFLAGS_MAINT_APPEND = -fPIC > > >> +export DEB_CFLAGS_MAINT_APPEND = -fPIC -fno-lto > > > > > ‘Esta mensagem é direcionada apenas para os endereços constantes no cabeçalho > inicial. Se você não está listado nos endereços constantes no cabeçalho, > pedimos-lhe que desconsidere completamente o conteúdo dessa mensagem e cuja > cópia, encaminhamento e/ou execução das ações citadas estão imediatamente > anuladas e proibidas’. > > ‘Apesar do Magazine Luiza tomar todas as precauções razoáveis para assegurar > que nenhum vírus esteja presente nesse e-mail, a empresa não poderá aceitar a > responsabilidade por quaisquer perdas ou danos causados por esse e-mail ou > por seus anexos’. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
