From mboxrd@z Thu Jan  1 00:00:00 1970
From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Subject: Re: Parallel (de-)compression
Date: Sun, 06 Dec 2015 23:21:37 +0100
Message-ID: <87k2orusjy.fsf@gnu.org>
References: <20151202184550.GA5741@debian> <87twnyi889.fsf@gnu.org>
	<20151206153142.GC4969@debian>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Return-path: <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:35260)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1a5hgg-00014q-Gd
	for guix-devel@gnu.org; Sun, 06 Dec 2015 17:21:47 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1a5hgd-0003wo-C4
	for guix-devel@gnu.org; Sun, 06 Dec 2015 17:21:46 -0500
In-Reply-To: <20151206153142.GC4969@debian> (Andreas Enge's message of "Sun, 6
	Dec 2015 16:31:42 +0100")
List-Id: "Development of GNU Guix and the GNU System distribution."
	<guix-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/guix-devel>
List-Post: <mailto:guix-devel@gnu.org>
List-Help: <mailto:guix-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=subscribe>
Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org
Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org
To: Andreas Enge <andreas@enge.fr>
Cc: guix-devel@gnu.org

Andreas Enge <andreas@enge.fr> skribis:

> On Fri, Dec 04, 2015 at 03:44:38PM +0100, Ludovic Court=C3=A8s wrote:
>> Are you saying that xz-compressing TeX Live to resend it to
>> hydra.gnu.org is too CPU-intensive?
>
> That depends on your definition of "too". In any case, on the Novena board
> with an SSD attached, CPU is the limiting factor during this phase,
> pushing the CPU load on one core to 100% (while the other cores are idle).

OK.

>> Another option would be to trade compression ratio for reduced CPU usage
>> by using, say, =E2=80=98xz -2=E2=80=99 or =E2=80=98gzip=E2=80=99.
>> We did something similar in 5ef9d7d to reduce CPU consumption on the
>> front-end.  Usually it=E2=80=99s much less important to reduce CPU consu=
mption
>> on the build machines, but your experience seems to suggest otherwise.
>
> If possible, it would be more interesting to leverage the several cores
> and not make sacrifices on the compression quality.

It=E2=80=99s not necessarily the best option to increase throughput: the bu=
ild
machine may be busy building other things, and thus unable to dedicate
all its cores to compression.

Dunno.

Ludo=E2=80=99.