[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJt8pk_uzeGDxLDXpCLVfMZta8YcKU87XBn3Xr5HCPEX4GSC7g@mail.gmail.com>
Date: Fri, 18 Sep 2026 15:34:32 +0200
From: Pavel Labath <labath@...gle.com>
To: Florian Weimer <fweimer@...hat.com>, libc-coord@...ts.openwall.com
Subject: Re: An async-signal-safe way to get thread’s stack
For anyone following this discussion, I want to mention that there's
now a parallel thread about this on libc-alpha:
<https://inbox.sourceware.org/libc-alpha/CAJt8pk94O9RDurrFJfjvpBPivSKCQ_dwZjL-FE6Ve83w4me4pw@mail.gmail.com/T/#me606f8e66a614785c60af81b79b7914666b28fee>.
I'm sorry for forking the discussion :(
On Wed, 9 Sept 2026 at 17:49, Pavel Labath <labath@...gle.com> wrote:
>
> On Wed, 9 Sept 2026 at 11:41, Florian Weimer <fweimer@...hat.com> wrote:
> > Exposing that information should be relatively straightforward. With
> > the process_vm_readv optimization, maybe that is already helpful?
>
> This is an interesting idea. Using a syscall for each memory access
> would be too slow, but using it once per page just might work. I'll
> have to play around with this.
>
I've done some measurements to estimate the feasibility of this
approach. Our current unwinder (which uses frame pointer chaining) is
quite fast and can unwind one frame in about 130ns. One
process_vm_readv call takes about 1800ns, which is about 14 times
slower.
This also roughly happens to be the ratio of frames per page. This
data is a bit harder to come by, but by sampling one specific
application I got an average frame size of 329 bytes (most of the
frames are small, but once in a while you get a big frame which pushes
the average higher). Other applications may differ, but I expect them
to be in the same ballpark. This works out to ~12 functions per page,
which means process_vm_readv would make the unwinder slower by a
factor of two.
Now, one can play some tricks and use a single process_vm_readv call
to check multiple pages for readability, that makes it slightly
better, but doesn't change the overall picture by much as the cost of
the process_vm_readv call increases with the number of pages it checks
(2 pages => 2200ns, 10 pages => 4600 ns). To achieve sufficient
performance, I think we'd have to cache the readability information
between the unwind calls, which then runs into the async-safe-tls
problem.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
