public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: "Paul Eggert" <eggert@cs.ucla.edu>, "Ondřej Bílka" <neleai@seznam.cz>
Cc: libc-alpha@sourceware.org
Subject: Re: Possible inline malloc alternatives: bitmap
Date: Sat, 03 Mar 2018 23:37:00 -0000	[thread overview]
Message-ID: <33c5daf6-c894-c815-b811-b416c175c68d@redhat.com> (raw)
In-Reply-To: <9c9121c0-a1cc-767c-497f-99156e4edae6@cs.ucla.edu>

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.

-- 
Cheers,
Carlos.

  reply	other threads:[~2018-03-03 23:37 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-02  5:54 Ondřej Bílka
2018-03-02  5:54 ` Ondřej Bílka
2018-03-02 18:20   ` DJ Delorie
2018-03-02 16:28 ` Carlos O'Donell
2018-03-02 20:21   ` Paul Eggert
2018-03-03 12:56     ` Ondřej Bílka
2018-03-03 20:24       ` Paul Eggert
2018-03-03 23:37         ` Carlos O'Donell [this message]
2018-03-03 23:40           ` Carlos O'Donell
2018-03-04 15:51           ` Ondřej Bílka
2018-03-04 11:59         ` Per call-site malloc specialization Ondřej Bílka
2018-03-02 23:00   ` Possible inline malloc alternatives: bitmap Ondřej Bílka
2018-03-05 20:32     ` DJ Delorie
2018-03-06 20:42 ` best-fit algorithm with bitmap heap Ondřej Bílka
2018-03-06 21:26   ` Ondřej Bílka
2018-03-04 14:07 Possible inline malloc alternatives: bitmap Wilco Dijkstra
2018-03-05 18:57 ` Carlos O'Donell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=33c5daf6-c894-c815-b811-b416c175c68d@redhat.com \
    --to=carlos@redhat.com \
    --cc=eggert@cs.ucla.edu \
    --cc=libc-alpha@sourceware.org \
    --cc=neleai@seznam.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).