From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) by sourceware.org (Postfix) with ESMTPS id 16F7A3969028; Thu, 19 Aug 2021 16:42:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 16F7A3969028 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 EB31A19F5B0; Thu, 19 Aug 2021 18:42:17 +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=CUf5hWG6Y6YOXr05zqq+60QzE1jFKlKCDnAlICq7w/8=; b=epcbddxfcWDtFslk7//bzpUEkd DHAXF/07dANyuNVVHYS+RGgHRyrFk3mEJKYiPI+f0+6rCHk7MshsUYI9N+etcnlY0sxwi19hB0Xz0 9pRzUWBGNkhomqBZa4Jt8q1DlFRtuKgH/6sezU2GYNIURKIzVH0mcbSE7ksZEN3pKvI0=; Received: from guillaum by bender.morinfr.org with local (Exim 4.92) (envelope-from ) id 1mGl7R-00028C-EV; Thu, 19 Aug 2021 18:42:17 +0200 Date: Thu, 19 Aug 2021 18:42:17 +0200 From: Guillaume Morin To: Adhemerval Zanella Cc: libc-alpha@sourceware.org, Norbert Manthey , Guillaume Morin , Siddhesh Poyarekar Subject: Re: [PATCH v2 0/4] malloc: Improve Huge Page support Message-ID: <20210819164216.GA6845@bender.morinfr.org> Mail-Followup-To: Adhemerval Zanella , libc-alpha@sourceware.org, Norbert Manthey , Guillaume Morin , Siddhesh Poyarekar References: <20210818142000.128752-1-adhemerval.zanella@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210818142000.128752-1-adhemerval.zanella@linaro.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, 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:42:30 -0000 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). 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. Guillaume. -- Guillaume Morin