From nobody Sun Feb 26 13:10:58 2023 X-Original-To: dev-commits-ports-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PPkXN4JYrz3tKPD; Sun, 26 Feb 2023 13:11:00 +0000 (UTC) (envelope-from matthias.andree@tu-dortmund.de) Received: from unimail.uni-dortmund.de (mx1.hrz.uni-dortmund.de [129.217.128.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "unimail.tu-dortmund.de", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PPkXN2v87z3Mgm; Sun, 26 Feb 2023 13:11:00 +0000 (UTC) (envelope-from matthias.andree@tu-dortmund.de) Authentication-Results: mx1.freebsd.org; none Received: from mandree.no-ip.org (p54a03c23.dip0.t-ipconnect.de [84.160.60.35]) (authenticated bits=0) by unimail.uni-dortmund.de (8.17.1.9/8.17.1) with ESMTPSA id 31QDAwHH019067 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sun, 26 Feb 2023 14:10:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tu-dortmund.de; s=unimail; t=1677417059; bh=q8EPytFv4+66RjK7NQae+6WfxzByypV796FRu9m4hhg=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=n1eFf2gANjNHhrxZkvnywa/yEpp6Im57da8s2KkdcypuMZwszWaea2041jTbnlg0R i4+6HuCFLsLIJ+DXhT9MOQNq3ABnNXIJp6LRvp8nsEoFtzY7xLoVQMqxMCTaRDDSRa pPBt+UC+xPKK94/SaT68qszjcq5+bl//bqdiuiok= Received: from [127.0.0.1] (localhost [127.0.0.1]) by ryzen.an3e.de (Postfix) with ESMTP id 98442CED120; Sun, 26 Feb 2023 14:10:58 +0100 (CET) Message-ID: Date: Sun, 26 Feb 2023 14:10:58 +0100 List-Id: Commit messages for all branches of the ports repository List-Archive: https://lists.freebsd.org/archives/dev-commits-ports-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-ports-all@freebsd.org X-BeenThere: dev-commits-ports-all@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: git: c8c2d4f22536 - main - lang/python3: allow using LTO on powerpc64 Content-Language: en-US To: Alexey Dokuchaev Cc: Piotr Kubaj , ports-committers@freebsd.org, dev-commits-ports-all@freebsd.org, dev-commits-ports-main@freebsd.org References: <202302241548.31OFmQ39049727@gitrepo.freebsd.org> <98e988fa-9c8b-abee-8357-1cacd7462014@tu-dortmund.de> From: Matthias Andree In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4PPkXN2v87z3Mgm X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:680, ipnet:129.217.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Am 26.02.23 um 13:26 schrieb Alexey Dokuchaev: > On Sun, Feb 26, 2023 at 01:00:19PM +0100, Matthias Andree wrote: >> Am 24.02.23 um 16:48 schrieb Piotr Kubaj: >>> commit c8c2d4f2253694802ef720f098c57800570ad2fc >>> >>> lang/python3: allow using LTO on powerpc64 >>> >>> It was recently fixed and will be available in 13.2-RELEASE. >>> Since LTO is not enabled by default, it's ok to make it available. >> >> Careful. LTO causes EXCESSIVE memory use for the build. >> I've had to disable it for a low-memory server I operate (amd64 based, >> but that's the LTO feature itself, not the CPU). > > I think most people just disable LTO because they don't have 256GB+ or > whatever amount of RAM it demands for arguably rather little gain. > > Putting OPTIONS_UNSET+=LTO in your /etc/make.conf makes the ports tree > much more usable. It depends how well software is written, and LTO can make a considerable difference. But it is extremely expensive currently, so it's probably easier to enable only on certain ports that really benefit at run-time. We would require something like a resource scheduler for poudriere or the ports build system, which tracks how much RAM and disk space we need on a certain port, architecture, possibly FreeBSD version, and with certain specific options. My builder has 16 GB RAM (virtually, it's normally in a virtual machine, but can boot natively) and building compilers in parallel usually fails. I have limited JOBS to like 6 or so. If the builds framework could track how much memory and disk space a certain build needed, and possibly the expected build time, it could make better decisions, for instance, if it dispatched a rust or llvm build, it would hold off on other compiler builds and instead build several dozen Perl or Python ports in parallel to rust.