From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-196639-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 6306 invoked by alias); 9 Jul 2018 19:51:14 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 6294 invoked by uid 89); 9 Jul 2018 19:51:13 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=
X-HELO: albireo.enyo.de
Received: from albireo.enyo.de (HELO albireo.enyo.de) (5.158.152.32) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Jul 2018 19:51:12 +0000
Received: from [172.17.203.2] (helo=deneb.enyo.de)	by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)	id 1fccBe-0000IR-Rh; Mon, 09 Jul 2018 19:51:06 +0000
Received: from fw by deneb.enyo.de with local (Exim 4.89)	(envelope-from <fw@deneb.enyo.de>)	id 1fcc85-00074t-Dd; Mon, 09 Jul 2018 21:47:25 +0200
From: Florian Weimer <fw@deneb.enyo.de>
To: esr@thyrsus.com (Eric S. Raymond)
Cc: Mailing List <gcc@gcc.gnu.org>,  Mark Atwood <fallenpegasus@gmail.com>
Subject: Re: Good news, bad news on the repository conversion
References: <20180709002754.962F43A4AA7@snark.thyrsus.com>
Date: Mon, 09 Jul 2018 19:51:00 -0000
In-Reply-To: <20180709002754.962F43A4AA7@snark.thyrsus.com> (Eric S. Raymond's	message of "Sun, 8 Jul 2018 20:27:54 -0400 (EDT)")
Message-ID: <87fu0sdwdu.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain
X-IsSubscribed: yes
X-SW-Source: 2018-07/txt/msg00138.txt.bz2

* Eric S. Raymond:

> The bad news is that my last test run overran the memnory capacity of
> the 64GB Great Beast.  I shall have to find some way of reducing the
> working set, as 128GB DD4 memory is hideously expensive.

Do you need interactive access to the machine, or can we run the job
for you?

If your application is not NUMA-aware, we probably need something that
has 128 GiB per NUMA node, which might be bit harder to find, but I'm
sure many of us have suitable lab machines which could be temporarily
allocated for that purpose.