From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (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) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 82D2F1F8C6 for ; Fri, 13 Aug 2021 21:37:50 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8488F3858020 for ; Fri, 13 Aug 2021 21:37:49 +0000 (GMT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) by sourceware.org (Postfix) with ESMTPS id DD274385843A; Fri, 13 Aug 2021 21:37:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DD274385843A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=morinfr.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=morinfr.org Received: from bender.morinfr.org (unknown [82.64.86.27]) by smtp4-g21.free.fr (Postfix) with ESMTPS id 06D8419F54D; Fri, 13 Aug 2021 23:37:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=morinfr.org ; s=20170427; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Gk1hFwU2v1GZy9lJSPOVObzlPEb1u2WiWqSo0KV7uUo=; b=FdwDHyH0KyjnvlL/dFNgHP5CA8 kOibaSfLOvhyPrUSn2Wc5ZnoBRYNl4rm4/v3OyGs3m1T3QneQ7LuxpNrF3QRrXFPXeganOlbfA8tg ZAGfpg//QiUBaG7Eu2N0Et+0jrEk6gxgT6fMVNt3GWHpPdB4M/cLJzz2UySmLerXKnlY=; Received: from guillaum by bender.morinfr.org with local (Exim 4.92) (envelope-from ) id 1mEerm-0002tt-L6; Fri, 13 Aug 2021 23:37:26 +0200 Date: Fri, 13 Aug 2021 23:37:26 +0200 From: Guillaume Morin To: Adhemerval Zanella Subject: Re: [PATCH 0/3] malloc: improve THP effectiveness Message-ID: <20210813213725.GA9384@bender.morinfr.org> Mail-Followup-To: Adhemerval Zanella , libc-alpha@sourceware.org, Norbert Manthey , Siddhesh Poyarekar , Guillaume Morin References: <20210813210429.1147112-1-adhemerval.zanella@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210813210429.1147112-1-adhemerval.zanella@linaro.org> User-Agent: Mutt/1.10.1 (2018-07-13) 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: , Cc: Norbert Manthey , Siddhesh Poyarekar , libc-alpha@sourceware.org, Guillaume Morin Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" Hello Adhemerval, On 13 Aug 18:04, Adhemerval Zanella wrote: > Although it does improve THP effectiveness, it does not provide the same > features from libhugetlsfs morecore implementation [2], since it does > use MAP_HUGETLB explicit on mmap. And I think this is not what we want > for glibc, it requires additional setup from the admin to mount the > hugetlsfs and reserve the pages with it outside from glibc scope. I certainly do appreciate the effort. But unfortunately this is not a usable replacement for most libhugetlblfs users (who actually want to use hugetlbfs). First, I'll argue to have THP supported directly in the allocator is probably a nice-to-have feature for THP users but probably not that critical considering you can just madvise() the memory *after* it's been allocated. Alternatively any malloc interposition scheme can do this trivially: afaik there were never an actual *need* for a morecore implementation in this case. There is no such possibility with hugetlbfs. It's either mmap() with MAP_HUGETLB or not. Second, THP is not a drop-in replacement for hugetblfs. hugetlbfs has desirable properties that simply do not exist for THP. Just a few examples: 1) A hugetlbfs allocation gives you a huge page or not at allocation time but this is forever. There is no splitting, re-merging by the VM: no TLB shootdowns for running processes etc. 2) Fast allocation: there is a dedicated pool of these pages. There is no competition with the rest of the processes unlike THP 3) No swapping all hugetlbfs pages. I would really like to discuss and/or maybe implement some schemable that allows to optionally use MAP_HUGETLB for all allocations (which would be a definitive improvement over what libhugetlbfs was doing) if that's workable for you. Guillaume. -- Guillaume Morin