From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id 7003C387090B; Mon, 4 May 2020 08:27:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7003C387090B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fw@deneb.enyo.de Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jVWRN-0004KC-5j; Mon, 04 May 2020 08:27:05 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1jVWRN-0007x2-0X; Mon, 04 May 2020 10:27:05 +0200 From: Florian Weimer To: nmanthey@conp-solutions.com Cc: libc-alpha@sourceware.org, Siddhesh Poyarekar Subject: Re: [[RFC][PATCH] v1 0/2] malloc/realloc with transparent huge page support References: <7bd30e6c-7ae8-4c03-a818-6309351b3df9@email.android.com> Date: Mon, 04 May 2020 10:27:05 +0200 In-Reply-To: <7bd30e6c-7ae8-4c03-a818-6309351b3df9@email.android.com> (nmanthey's message of "Mon, 04 May 2020 09:27:14 +0200") Message-ID: <877dxsw1eu.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 08:27:08 -0000 * nmanthey: >> Still, it is easier to change a run-time kernel setting than to >> upgrade glibc. > > That is something I do not have control over. Hence, I would offer > the ability to running processes. Statically linked binaries could > come with their own modified glibc; and for such a purpose these > patches are valuable. There might also be scenarios where not all > processes should get huge pages, so being able to enable this on a > per-process level looks reasonable to me. I'm not sure if it is a good idea to work around kernel problems in glibc just because it happens to work in your setup, given your local constraints. It may be time for per-namespace/cgroups settings for hugepages, though. >> I suggest to repeat the experiment with "always". There is a reason >> why this setting exists. The results presented so far are incomplete. >> >> The paper doesn't provide details on the NUMA configuration of the >> test system, so one has to wonder if there are any surprises there as >> well. > > I agree, and I can look up the numa configuration. Even with less > performance increase, as a unprivileged user, I would like to enable > THP. > > Do you have a specific ask of what else should be measured? I'm not a virtual memory management or performance expert. I will ask around. The immediate problem I see is that requesting transparent hugepages in this way forces the kernel to perform more aggressive defragmentation, which can hurt overall system performance if processes are shortlived.