From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Wilco Dijkstra Newsgroups: gmane.comp.lib.glibc.alpha Subject: Re: [PATCH v2] Add malloc micro benchmark Date: Wed, 28 Feb 2018 17:01:57 +0000 Message-ID: References: <6ad98d83-d49b-25a3-ef01-e93e18f4740b@redhat.com> <96b76d58-d2f0-2176-51e5-f6338ed079e1@redhat.com> <165192eb-d815-867f-e1ba-0f9972eb19cd@redhat.com> <20180228141126.GA13073@domone> <808ed1e2-5945-0712-87a5-a0408de55fb0@redhat.com>,<20180228164621.GA10445@domone> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1519837209 31017 195.159.176.226 (28 Feb 2018 17:00:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Feb 2018 17:00:09 +0000 (UTC) Cc: Carlos O'Donell , Joseph Myers , "libc-alpha@sourceware.org" , nd To: =?iso-8859-2?Q?Ond=F8ej_B=EDlka?= , Florian Weimer Original-X-From: libc-alpha-return-90685-glibc-alpha=m.gmane.org@sourceware.org Wed Feb 28 18:00:05 2018 Return-path: Envelope-to: glibc-alpha@blaine.gmane.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id:references :in-reply-to:content-type:content-transfer-encoding :mime-version; q=dns; s=default; b=O9tEfG/JxQXiYntQW/WDt/6yHgQfn b8P04VgcoYZFGrICHQMlRvd4/5WpAC7XE69MwGiE/GltQf/psVq2wsBcgBDqAGYW 7Tpc9SWDOKESXAQjwIQLurcLtmvJPsILwSpNILkSAIoCNldhhMAPgtfVyaY+l+l3 3GYQ59jP4uvTOk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id:references :in-reply-to:content-type:content-transfer-encoding :mime-version; s=default; bh=7hndDOdQfKS4BiC5WgRhLAlbOik=; b=HEV lTjX5rFf4wnSuxJwTqiknK2lfZxQ4yEhQ0LofryEDKhMe67xZL+kMxp8BKlCGOTk Sut6cVUEjehNKWAatIYO/Xy3MMEEKv+uHkxjDcWVtM8Kg8h+MFsnN78xJ5quEauD uJ6qYiZRGfsCV5i0jMFssfCpCE0/8Xbfg79B7SyY= Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-exchange-antispam-report-cfa-test:944501217 X-HELO: EUR01-DB5-obe.outbound.protection.outlook.com In-Reply-To: <20180228164621.GA10445@domone> x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;DB6PR0801MB1656;7:OztLwNGIZc6O69fKqSJkXR/ZwR6e9kRcn4S4Nm0JgWoDNXvTXNf7D9o3eRXXkDHDVuOMwIcg9tpr9qTilJxN0UhjNywnGcUut/kPMNV/wpmobl495AxC02JIWWR3HxOGVZbT5i5dNWgEdBqFAhdjAMpgNaGx7fffuA5KVHkhIPzyI9yN5ZKCzYrzMheVc0ixNNDafjKx9gMbR5CVOofChHUfcyu/gqrmDnqnkaCvyAS5Ppxf0kmHXU1ZOYV/XnPy x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6cdb8e39-421b-44a3-8eb6-08d57eccf9f2 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020);SRVR:DB6PR0801MB1656; x-ms-traffictypediagnostic: DB6PR0801MB1656: nodisclaimer: True x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(8211001083)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231220)(944501217)(52105095)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011);SRVR:DB6PR0801MB1656;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0801MB1656; x-forefront-prvs: 0597911EE1 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(396003)(39860400002)(39380400002)(366004)(346002)(376002)(199004)(189003)(68736007)(53936002)(54906003)(106356001)(97736004)(3846002)(9686003)(6436002)(3660700001)(3280700002)(6246003)(105586002)(6506007)(102836004)(6346003)(33656002)(26005)(55016002)(8676002)(5660300001)(2906002)(6116002)(8936002)(5250100002)(66066001)(81166006)(81156014)(2900100001)(7736002)(4326008)(14454004)(305945005)(74316002)(25786009)(229853002)(76176011)(478600001)(99286004)(7696005)(2950100002)(72206003)(110136005)(316002)(86362001)(186003)(93886005)(8656006);DIR:OUT;SFP:1101;SCL:1;SRVR:DB6PR0801MB1656;H:DB6PR0801MB2053.eurprd08.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Wilco.Dijkstra@arm.com; x-microsoft-antispam-message-info: ueDZ6E3XSNb8EfBkU/UhyE2AvOCwM0zC/vDFiNk/GYyCNKqtxOfpc7xqoEsgdWgiG+MMwlRsE/Qpy9Awzfltm9/tBQUTLnnFjA5WyVNu+KeMwfEY2HvvYmPEGDspxnkB0DjmFr6fYPBU3u+u1GSlaTdo6NQ73U508oPzrvjAisY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6cdb8e39-421b-44a3-8eb6-08d57eccf9f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2018 17:01:57.3550 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1656 Xref: news.gmane.org gmane.comp.lib.glibc.alpha:83016 Archived-At: Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1er55I-0007Xp-Be for glibc-alpha@blaine.gmane.org; Wed, 28 Feb 2018 18:00:04 +0100 Received: (qmail 97391 invoked by alias); 28 Feb 2018 17:02:07 -0000 Received: (qmail 97359 invoked by uid 89); 28 Feb 2018 17:02:06 -0000 Ond=F8ej B=EDlka wrote: =A0=20 >> I think a heap-style allocator which does not segregate allocations >> of different sizes still has its place, and why not provide one in >> glibc? >> > That isn't case for any allocator and it is asking for trouble. You want > to avoid sitation where two big chunks couldn't be merged because of > tiny chunk between them. Agreed, you always want to special case small blocks. I don't believe there= is any advantage in using a single big heap. > For larger size this representation is still problematic and you could > improve performance with another representation that also avoids > alignment problem by placing metadata elsewhere(for mine only 4 bytes are= needed). Larger sizes would be helped a lot once small blocks are dealt with separat= ely. So I don't think we need complicated balanced binary trees when dealing wit= h a small number of large blocks. You won't need an unsorted list either, large= blocks can be merged in O(1) time. There may be an advantage to place meta data elsewhere, for example it coul= d make adding/removing/walking free lists much faster (spatial locality) or to mak= e heap overflow attacks almost impossible, Wilco