public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
To: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Cc: "dj@redhat.com" <dj@redhat.com>,
	'GNU C Library' <libc-alpha@sourceware.org>
Subject: Re: [PATCH 00/16] memory tagging improvements
Date: Mon, 8 Mar 2021 09:34:01 +0000	[thread overview]
Message-ID: <20210308093358.GW12795@arm.com> (raw)
In-Reply-To: <VE1PR08MB5599E15BF7D9237DA52E9A1083969@VE1PR08MB5599.eurprd08.prod.outlook.com>

The 03/05/2021 21:36, Wilco Dijkstra wrote:
> > - request2size and checked_request2size are not consistent which looks
> >   wrong (likely works in practice other than some sizes don't end up in
> >   fastbin or tcache that one might expected to, but i think this can
> >   break easily). Fixing it is not obvious because of assumptions about
> >   the chunk layout that is no longer true with mtag enabled.
> 
> It's better to change request2size to round up differently if tagging is
> required. That avoids dynamically changing how chunks are rounded up.
...

> > - unconditional top byte zero
> >   internal data is tagged 0, only user allocation is tagged non-zero
> 
> That's a great idea! Many chunk2mem can be changed into chunk2rawmem
> approximately halving the overhead. And mem2chunk can unconditionally mask
> out the tag (note all this could be made target-dependent if needed).

i will look into this, i expected it to need bigger changes.

> > - unconditional layout
> >   padding up to tag granule can be done unconditionally
> >   good: no runtime check, same layout with and without heap tagging.
> >   bad: wasting space with small allocations, design change.
> 
> This is unconditionally good for performance and avoids the request2size oddities.
> If we're worried about memory usage, we need to talk about modern malloc
> implementations that don't add a 16-byte header to every block.

i think it is not enough to change request2size, one would
have to audit the code for hidden assumptions about the
layout, so even if we are happy to waste another word per
small allocations, it is not an obvious change.

(right now the logic is a bit ugly, but the ugliness only
affects behaviour in the tagging case)

  reply	other threads:[~2021-03-08  9:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-05 21:36 Wilco Dijkstra
2021-03-08  9:34 ` Szabolcs Nagy [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-03-04 16:30 Szabolcs Nagy

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=20210308093358.GW12795@arm.com \
    --to=szabolcs.nagy@arm.com \
    --cc=Wilco.Dijkstra@arm.com \
    --cc=dj@redhat.com \
    --cc=libc-alpha@sourceware.org \
    /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).