From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85170 invoked by alias); 3 Mar 2018 23:40:12 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 85144 invoked by uid 89); 3 Mar 2018 23:40:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=coordinate, docs.google.com, docsgooglecom, UD:docs.google.com X-HELO: mail-qk0-f179.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=tSC5Qha+He8grr9AbLuxMGu8PIGekw+xPHG8ybzWQh4=; b=n1ePGfL7XP44kCv1TaNdpS2MrRfktV04WmAmVtEJbgAV/JqKIQ6qleST7d1vpo3/X/ 4mn+wfwkRYS6LeDxOaElmn5PRxDKrxdmsQKel2ZVTQa3omSaem/gHKKLEw+3lO+vk7wJ R7v5UOaNb+SvA62JD2wzfw4Sfe5HD4LYRRSpqkS8lHnwEJ5TumxZO9pCOBGCRDQolCn2 AL7MGsSxYh89ASqGYsgU4Ill1IH2xLRw425nnHhV8VqcLs9JIvbJUjltZUQJ9T6ogXLJ sAdc7Zi7kS4/xlEIkB3fjnXaDIFvYrNkY1FZvaB/1NkNNN7jyK5adO8IN3YBya7pR0Yo N9pg== X-Gm-Message-State: AElRT7FLttS5rKeTSMVaFjzoagFdgNWGl/iMARteZD//5aCrMiweQBvZ eJ7u2ziGoJddD8cSNjZN3joi/rR8EfE= X-Google-Smtp-Source: AG47ELuY7jxKBVW9O1dtfgFq0k8jfvu8R37ztzzDEwBy8t5nkuzylGMCCm0C5SuUPTo5XXlFyVA5gg== X-Received: by 10.55.31.20 with SMTP id f20mr15650552qkf.290.1520120408592; Sat, 03 Mar 2018 15:40:08 -0800 (PST) Subject: Re: Possible inline malloc alternatives: bitmap From: Carlos O'Donell To: Paul Eggert , =?UTF-8?B?T25kxZllaiBCw61sa2E=?= Cc: libc-alpha@sourceware.org References: <20180301213318.GB3062@domone> <085a3206-4ae8-5d0a-800c-134d9d508ba1@redhat.com> <6d67177c-4cfe-4eba-ab27-6f75d74ca63e@cs.ucla.edu> <20180303125546.GA6516@domone> <9c9121c0-a1cc-767c-497f-99156e4edae6@cs.ucla.edu> <33c5daf6-c894-c815-b811-b416c175c68d@redhat.com> Message-ID: Date: Sat, 03 Mar 2018 23:40:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <33c5daf6-c894-c815-b811-b416c175c68d@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-03/txt/msg00072.txt.bz2 On 03/03/2018 03:37 PM, Carlos O'Donell wrote: > On 03/03/2018 12:24 PM, Paul Eggert wrote: >> I didn't quite follow your profiling proposals. As near as I can make >> out you'd like to log calls to malloc, free, etc. But for good >> results don't you also need to log memory accesses? Otherwise how >> will you know which objects are hot? > > We can already log malloc, free, etc. with the inlined tracing code we > have on DJ's branch, and we in turn simulate those traces again. > > You only need to log memory accesses if you want perfect reconstruction > of the various memory subsystem effects. As you know this is obviously > very expensive and difficult if not impossible to do. Some suggestions > at LPC were provided though, including tracking heuristics or statistical > profiles of hits/misses and trying to recreate those profiles in the > page-touch heuristics used by the simulator (something it does when it > gets a new block of memory). > > Today we mostly use the simulator to look at in-use RSS, RSS max, > and external and internal fragmentation, looking at trying to reduce > that as much as we can. > > Actually using it for profile driven feedback is very hard, and that > kind of behaviour seems to be largely derived from first principles > in most academic work. > This is a link to the tcmalloc work which we are trying to coordinate with: https://docs.google.com/document/d/1S8T9apA2juEC5sV2UVXUan4e4_029fTmoAEoX7MEB9s/edit#heading=h.ljaekvl39oaq -- Cheers, Carlos.