From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14065 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: Thread-local memory for thread structures Date: Thu, 11 Apr 2019 16:41:17 +0200 Message-ID: <20190411144117.GG18043@voyager> References: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="3877"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-14081-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 11 16:41:53 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hEath-0000pD-Fv for gllmg-musl@m.gmane.org; Thu, 11 Apr 2019 16:41:49 +0200 Original-Received: (qmail 22221 invoked by uid 550); 11 Apr 2019 14:41:47 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 22203 invoked from network); 11 Apr 2019 14:41:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1554993695; bh=Dz5c0/oFAvsRb2yoc+9EVRHlDae+jf+dhFYmlYivjbE=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=LC355Z754JNoyq0QkU/J+0Y83HW7yPY99J0eCtorDfx/hv1js62XDensBiVFbyO/n gwHki1SZPgsU0gIjYvTd7oQ+NnMRVMt25clylnkHJ2i+MF1b/pxcjmsNZ9SBXI+1Y5 YCmmJG+1lhmwW/VsPeK31loSwdo5qQSNby08r2Zk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:6PK0yqkKU7alNFkXIg/5eJtFZPBa/NlaGyq+wejPVwwuJyUIjLA SuylafBVEra2vMaqSH/ByenxEP26wqlSWqhhJkC1WwxbFO1Jdo88y9pbXjtyg2jKeC+OoPB 7sfBGpIQBVUgyI5Jx6WvH2AOTMmOyyMpCvaLNaYHN6yh99azG4Ewss+4dC8d+5RfHfqrsNg PdhMlSWdxKqAxrFjbnYNw== X-UI-Out-Filterresults: notjunk:1;V03:K0:dF1g+WTcuQc=:iCsATkJ0Vl2rhzg7L2et0M vz5h6svn7ZfDKTrAVUjCVKEYzeBe4QWB9ACEgWp+gzBwsq1k7OB+UTS9TYhXNuAMTl/pDv8kj QgYidGkT4mdt6rxqtrWMeEFWp34gmNK7NfmFHlGjHuB1zAa9K+3GdPTiEGqTrSnh4PLjh/NKx u/dl5mA80BCbvVcgtieKOgZTd9NorSpsKn9XTLwFQ8DDud3oaqK8WxDdfSNey37TMNKEjWD2P G+uOohaxWp0wE4IZ5moh4LIOK7n3+w+HdEqDakF320x/GNMuBo4QiMLZLbpbGf1lOdamkREer VVpGunSyAkdIiy+PZaBUDr2LZPdi8gKhSLeNFTgwtPQVEDBhEKoI7DShIWpUqx5WFnI7CbAnO Db6RoTIBQBR6upCJrV2b33J4Lu3Ry662vEivCrKmQSuG9C3VmJFXumYx3TBOphm9mU3iTpdo0 bXXU6ir/mAFdOUbWdLMm/t9pkSaDTCP65UN/aFl+7nFYcc8zfDpTAekISuo9PcPDW03n+yAoz TLcQ4ncjcz92MRL67fFmt3pdg8D1LDCdGpliQi48vw8vjBuiPmA5UGxyLU2ANtb2NTesP4yQz xU8VJU9QOgetTE+vgQrQW1o/qhwEr52aZTHQWQ5TEZQtqPT+jujp48jyF0lfXhMo5jEoVKUE6 pL0oT18bm7VbSpUmphFV68dCSbAj+XDCIij/cyCaVp3DBm9y0dULeJapd39njAhKBvkdaBU/9 6pY+Bns0ustbbOdrXhnb436xdB8k8S/fleHJvYbPNYLXRLVDL4F1gukeuu4VyUEb8cZSJUY6 Xref: news.gmane.org gmane.linux.lib.musl.general:14065 Archived-At: 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