From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id D72243857817 for ; Thu, 19 Aug 2021 12:42:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D72243857817 Received: by mail-pl1-x62b.google.com with SMTP id u1so3871006plr.1 for ; Thu, 19 Aug 2021 05:42:53 -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:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fZ1MRtCF2r8F7qHIxppKCA1pVmVPvnwO0v3c40sAvq8=; b=kqksg7BH3MswBN/gbCxymg+94fGwsaUqB/DgfWWHgfpnrP/EOMqbkPY7NPsEvoZw2R QUt3+8Z11DXh/ox95FGraMdLqH4q7qGTEMfSozF3dFT6HfpAbyDIFut5rWFv9lD6Q2c4 zHIBjZzUtjajJZoN/hhthJOMCpCp2IavACgLmoPLZx8t1Vhc110RzN9DvDvAaJpkZbF7 OGVPeeqZOeu3Rq14QDlwhQM1kaCp4+Eh4lvOVWuNYC4Z2/7I0eJ0m7aVj7JLsWcohLoH t4ZkUM8EK649QEBVXOpVhWFAHCdPjJpFFYomKkfdCIAn8s6QUWgdbRzvdnpweOfCEDUf vNGg== X-Gm-Message-State: AOAM532yUsFIBSNjcSmKg0NYtlPlcZ2cNOZDaPQTpPSkWDWutCE/fuRr 3F+ThM1bvHthp1DYRtffAvG9yA== X-Google-Smtp-Source: ABdhPJwWvalVeXWunBlXnP0NtFOEBrcK0OWmZX2HIWtwBW2u5iFDbE+K6LFoOL/DIQSSeqs2omxbIA== X-Received: by 2002:a17:90a:448f:: with SMTP id t15mr14847934pjg.21.1629376972982; Thu, 19 Aug 2021 05:42:52 -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 e3sm3405132pfi.189.2021.08.19.05.42.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Aug 2021 05:42:52 -0700 (PDT) Subject: Re: [PATCH v2 0/4] malloc: Improve Huge Page support To: Siddhesh Poyarekar , libc-alpha@sourceware.org Cc: Norbert Manthey , Guillaume Morin References: <20210818142000.128752-1-adhemerval.zanella@linaro.org> <5e37cb66-fd93-5d27-ec7b-28f7cf636246@linaro.org> <9c13a602-573a-666f-071c-f88c1f857b5c@sourceware.org> <21440481-f2b2-8112-1d7f-be59eb43c80e@linaro.org> From: Adhemerval Zanella Message-ID: <0713ec2f-94c7-6041-5765-7e1c7880312d@linaro.org> Date: Thu, 19 Aug 2021 09:42:50 -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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.0 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 12:43:04 -0000 On 19/08/2021 09:26, Siddhesh Poyarekar wrote: > On 8/19/21 5:34 PM, Adhemerval Zanella wrote: >> I think this would be an additional tunable, we still need to handle >> the case where mmap() fails either in default path (due maximum number >> of mmap() per process by kernel or when the poll is exhausted for >> MAP_HUGETLB). >> >> So for sbrk() call, should we align the increment to huge page and >> issue the madvise() if the tunable is set to use huge pages? > > Yeah it's a reasonable compromise.  I've been thinking about getting rid of max_mmaps too; I don't see much use for it anymore. I think it made sense when mmap() is way costly, specially for 32-bit architectures. On Linux it is still controlled by a tunable, /proc/sys/vm/max_map_count, so it might still be case where might want to avoid the overhead of the mmap failure and fallback to sbrk() directly. But I agree that for usual case where mmap() is used it does not make much sense to try use the tunable, since for cases like threaded programs sbrk() does not help much.