mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Subject: Re: Thread-local memory for thread structures
Date: Thu, 11 Apr 2019 16:41:17 +0200	[thread overview]
Message-ID: <20190411144117.GG18043@voyager> (raw)
In-Reply-To: <CACCP0Gq23AjxF9dOfGysWUsZLMTEjHR_+tDy=QKmTK-duaNxpQ@mail.gmail.com>

On Thu, Apr 11, 2019 at 12:12:46PM +0100, Raphael Cohn wrote:
> Dear List,
>
> I'm playing around with allocating 100s of bytes of TLS memory for
> various purposes. Something I noticed in the code for creating the
> mmap'd memory for TLS is that it does not (quite reasonably) assign it
> a NUMA memory policy.
>
> I'd like to assign a NUMA memory policy to the memory used for
> managing a thread. Is there anything 'underhanded' I can do to find
> out its location and size? I realize anything is likely to be brittle.

Worse, it's going to be arch-specific.  Location of the thread-local
memory is easy, however, you just read the thread pointer. Basically,
you follow your arch's ABI to find the TLS base pointer from the thread
pointer, which must be in some kind of register.

Finding the size is less easy. In the statically linked case, you can
just read the program headers with getauxval(AT_PHDR) to find the size
to the PT_TLS segment, but in the dynamically linked case, you would
then have to add up all the sizes of the TLS segments of all the
linked-in libraries. But you don't know their base pointers, only the
libc does. Well, you /could/ parse /proc/self/maps.

But at least once you add dlopen() into the mix, the task becomes next
to entirely infeasible. You'd have to parse /proc/self/maps again after
each dlopen(), find out the libs you missed earlier, and then add their
TLS sizes to your total. And then ring up every thread to tell them the
size has changed.

> Ideally what I'd like is a 'set NUMA memory policy of this thead's
> mmap'd management memory to the local NUMA node [once I've scheduled
> it to run a particular set of CPUs].
>
> Any suggestions?
>
> Raph

If the manpage is to be trusted, then:

| The thread memory policy is preserved across an execve(2), and is
| inherited by child threads created using fork(2) or clone(2).

So, you could use set_mempolicy() to set MPOL_LOCAL before spawning
threads. Of course, that would be horrible for shared memory, but that
is a cross you have to bear.

Ciao,
Markus


  reply	other threads:[~2019-04-11 14:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11 11:12 Raphael Cohn
2019-04-11 14:41 ` Markus Wichmann [this message]
2019-04-11 15:09 ` Rich Felker

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=20190411144117.GG18043@voyager \
    --to=nullplan@gmx.net \
    --cc=musl@lists.openwall.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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 NNTP newsgroup(s).