From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by sourceware.org (Postfix) with ESMTPS id DE84A3857832 for ; Thu, 19 Aug 2021 16:55:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DE84A3857832 Received: by mail-pf1-x432.google.com with SMTP id m26so6054995pff.3 for ; Thu, 19 Aug 2021 09:55:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zyGut6++6B8d7lHFzr4dh5Dak4ZnKNAqZ90OPyHdPtE=; b=NhjwNRL2hNSms4cxk4x9moH2a1UCRdDtulodLZQVae/UaRrGJh3V0nTL8HUTpkv9gf kxDNg7meJmnp5nMdZLQtgNlCox8TyxVAKmltZbvNt9zgYcYJgbiD2B3jNWuHHRWUzfPj rDyxv1dpcpssLOw8mbPERwGOs04CmtRdm4n8RttJsmbS90t375XisTlJ3PiqnKDa0+eu FHDZrUr4BDWw3zWLPnYejJaLLUE6NjPWihGy90YiTpfVn7Q7wd5Ha0LVxTuFAKnMzIZ9 C9W9POwfRq1rTorUGivx+FJRYptw0V7mOVmgGfxjZ67wXrY8wYiTktIadgq4x2hl/4va jRVQ== X-Gm-Message-State: AOAM530Y6kKRHE7soKuRZqsvMJ2hOJyrzhLVKFcG4anpB3FJwOq7Vk2r b43xSpixd2MiDkaRylMAmLvNNg== X-Google-Smtp-Source: ABdhPJytlwSKDrYEStjuEg3javXL9zvupiZ0VzPAhunLxHXWgORiUVsWcwZU/uPKg9coMTUaq3jE8w== X-Received: by 2002:a63:ff5e:: with SMTP id s30mr15145867pgk.390.1629392127021; Thu, 19 Aug 2021 09:55:27 -0700 (PDT) Received: from ?IPv6:2804:431:c7ca:cd83:aa1a:7bd:9935:9bba? ([2804:431:c7ca:cd83:aa1a:7bd:9935:9bba]) by smtp.gmail.com with ESMTPSA id w8sm6073396pjd.55.2021.08.19.09.55.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Aug 2021 09:55:26 -0700 (PDT) Subject: Re: [PATCH v2 0/4] malloc: Improve Huge Page support To: libc-alpha@sourceware.org, Norbert Manthey , Guillaume Morin , Siddhesh Poyarekar References: <20210818142000.128752-1-adhemerval.zanella@linaro.org> <20210819164216.GA6845@bender.morinfr.org> From: Adhemerval Zanella Message-ID: Date: Thu, 19 Aug 2021 13:55:24 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210819164216.GA6845@bender.morinfr.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Thu, 19 Aug 2021 16:55:38 -0000 On 19/08/2021 13:42, Guillaume Morin wrote: > Hi Adhemerval, > > On 18 Aug 11:19, Adhemerval Zanella wrote: >> Linux currently supports two ways to use Huge Pages: either by using >> specific flags directly with the syscall (MAP_HUGETLB for mmap(), or >> SHM_HUGETLB for shmget()), or by using Transparent Huge Pages (THP) >> where the kernel will try to move allocated anonymous pages to Huge >> Pages blocks transparent to application. > > This approach looks good to me! This is much appreciated. > > Are you planning on tackling using the same tunables to allocate > additional heaps (in arena.c)? > > It's a little more subtle because of the calls to mprotect() which needs > to be properly aligned for hugetlbfs, and probably for THP as well (to > avoid un-necessary page splitting). What do you mean by additional heaps in this case? > > One additional thing to address is the case where mmap() fails with > MAP_HUGETLB because HP allocation fails. Reverting to the default pages > will match what libhugetlbfs does (i.e just call mmap() again without > MAP_HUGETLB). But I see that Siddhesh and you have already been > discussing this case. This is what I did in my patch, it follow the current default allocation path.