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=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,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 53DA61F8C6 for ; Wed, 14 Jul 2021 18:52:00 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4A5483988033 for ; Wed, 14 Jul 2021 18:51:59 +0000 (GMT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by sourceware.org (Postfix) with ESMTPS id BC3B339874D2; Wed, 14 Jul 2021 18:51:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BC3B339874D2 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 0A93B19F522; Wed, 14 Jul 2021 20:51:47 +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=47q7ll+kblaSuYXHDx26emHIYWwRMB3M/4ZsYJMXYpA=; b=p5EUQPaqWvV11Ux+uUIHcLDjC1 FYLU5j90q+X3BAKQ1G7VJ2gT16KkSzYZ9qTJRPpP2z60qAiN0Zx2ZhCw7z9S3EHzeYPsOamaR6HSl CDbUKn2MQjn41s0NoAjn9fjk8kK5gNP2FHo/d3aNJBhPwRLMenh3ZrFRIA2odOgRDc9w=; Received: from guillaum by bender.morinfr.org with local (Exim 4.92) (envelope-from ) id 1m3jz1-0005kN-LD; Wed, 14 Jul 2021 20:51:47 +0200 Date: Wed, 14 Jul 2021 20:51:47 +0200 From: Guillaume Morin To: Siddhesh Poyarekar Subject: Re: [PATCH v8 03/10] Remove __morecore and __default_morecore Message-ID: <20210714185147.GD16858@bender.morinfr.org> References: <20210713073845.504356-1-siddhesh@sourceware.org> <20210713073845.504356-4-siddhesh@sourceware.org> <9925362a-d278-a0ad-f504-ae08ca93f628@gotplt.org> <20210714125415.GA24678@bender.morinfr.org> <45ba79b4-02e6-fae5-ae9b-db6c8a01aecb@gotplt.org> <20210714164204.GA1103@bender.morinfr.org> <6364b66d-14a8-3086-00ad-a0def6995c54@gotplt.org> <20210714182551.GA16858@bender.morinfr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: fweimer@redhat.com, Siddhesh Poyarekar , Guillaume Morin , libc-alpha@sourceware.org Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 15 Jul 0:13, Siddhesh Poyarekar wrote: > This seems to be the central the point of difference. A contract for an > interface like that is not limited to hugetlbfs. I do agree that it does seem to the central point of contention. I am still a little confused about why that is though. The contract is: pass a size_t, return the previous break. No other inferface necessary, mo special case or anything necessary in the malloc code. You only need to provide the default implementation that is just a straightforward call to sbrk(). > That said, Adhemerval's suggestion is perhaps a good compromise. I'm far > more comfortable with a tunable chosen hugetlbfs morecore implementation > within glibc since it does not have any arbitrary interface contracts that > we may be obliged to maintain indefinitely. If that's workable, I do prefer this solution as well. A tunable is stricly better. -- Guillaume Morin