UPDATE Re: making use of userland dtrace on FreeBSD

[Konstantin Belousov]

On Wed, Dec 26, 2012 at 09:32:45PM -0800, Peter Wemm wrote:
> I myself have killed patches that turned out to be premature
> optimizations because it actually didn't make any difference.  For
> example, I never committed the lazy tlb shootdown to AMD64 because it
> made things slower on the hardware of the day - opteron silicon had
> *hardware* address space tags on their TLB and the lazy shootdown code
> just added more synchronization work that just added overhead..  eg:
> buildworld was around 2% slower with the patches.
Recent Intel CPUs have hardware TLB tags too, but there it is explicit.
I have a patch for amd64 pmap which starts using PCID, but the measured
effect was non-existent. My guess was that there were two factors.

One is the need to do large amount of shootdowns due to buffers
creation, hopefully fixed soon.

Another one is the Intel only adding instructions to shot the TLB entry
in the non-current PCID starting with IvyBridge, so sandy machine which
I used to benchmark had to do switch PCID; invlpg; switch PCID back to
the current.

> >> Of course it wouldn't be required with dwarf unwinding awareness, but
> >> we don't have that.
> >>
> >> We have -fno-omit-frame-pointer on the amd64 kernel whenever debugging
> >> is compiled in because there's no unwinder for doing stack traces.  We
> >> need a dwarf2+ unwinder and somebody to instrument the call frame
> >> state through the remaining assembler code.
> >>
> > How much work is that exactly?  I've only been a gdb user, not a hacker.
> 
> gdb has a stack unwinder.  kdb/ddb/stack(9) do not.  There's well
> established GPL code to do it, as well as libunwind and variants.
> Basically what this code has to do is run the dwarf2+ state machine to
> find all the call/return frames instead of assuming the compiler did
> it.  Heck, even glibc has a dwarf2 unwinder built into it as part of
> their exception processing system.
Our libc also calls libgcc unwinder for cancellation.

> 
> I'm not entirely sure what more work src/lib/libelf and
> src/lib/libdwarf need.  It looks like its got just enough implemented
> to support the ctfconvert etc and doesn't have an unwinder in it.
BTW, I once sit and did the annotations for the amd64 asm. I had no time
to test all the bits, and I know that my hack in siglongjmp to handle
the switch to the new stack seamlessly does not work, at least for gdb.

http://people.freebsd.org/~kib/misc/amd64_unwind_annotations.1.patch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20121227/abe5ee9d/attachment.sig>