Date: Thu, 27 Dec 2012 20:47:04 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Peter Wemm <peter@wemm.org> Cc: "arch@freebsd.org" <arch@freebsd.org> Subject: Re: UPDATE Re: making use of userland dtrace on FreeBSD Message-ID: <20121227184704.GK82219@kib.kiev.ua> In-Reply-To: <CAGE5yCrnoNhOh3VaYU3bO6BwA=bpxD5QzkZvD%2BHaUwvXNQ%2BUfw@mail.gmail.com> References: <50D49DFF.3060803@ixsystems.com> <50DBC7E2.1070505@mu.org> <CAGE5yCq46NFKKzSUZq=jz0NwEnWdjPTK_0fpZ%2BwWV9FA0BSQCg@mail.gmail.com> <50DBD193.7080505@mu.org> <CAGE5yCrnoNhOh3VaYU3bO6BwA=bpxD5QzkZvD%2BHaUwvXNQ%2BUfw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--YZQs1kEQY307C4ut Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. >=20 > 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 --YZQs1kEQY307C4ut Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ3JenAAoJEJDCuSvBvK1B0QsP/1O6QwzqydH+nN1pcztGEnvB NjXxgTzW5IXb5bN8FuJ4EUNR1zfDIVT6A+i5VYmJO+PmhQScro9B60noIp2Yzuq6 jWJPgsf/ggvcruSpaV95cqdZjGruJ7zlgoa2cf05xven+5kXymV2Wnrmc87TlnbW xWKSjtvteEgtGzKadbdF7m6+iipvX3B1G2OVh5bMO7geQUAjysLj2sT08dvGU6eW v2vGbKcMe+O20EHLGHpBOrTBts0JzwW+vXI1tCPFcUXtVpRmV9Sg2+JbJyGLUk61 9lGoKGv2k1BAjRH/5dOf4TKxqWYOKCp1xa2ZK4uEnf9giVnLgcl5WHFefdpRKA6L +fOuqHtxMnln1BI2vs8MYjtsIeQlyA2XaESK/CKTw5vG3ln3jy1a2sW1EvGEpvt8 CkaHPzaghMpj2ZBKuKSTujKIRibB+oVlFh06AnEJoZyfdHoCjqrs8SCd/IwA7PBY h0KDsNBJlcKeRR8eLaAoTTa85FkdB4yTP8PTV6F1t2TvKl0pcng7yE8i1aDcbX6U gAH5L7vLAOmkTB+WBMayxvcCd4FA7n7kwszdXaw656hKGoTXiFsnDJ1ooJaZUAnu rKihq0zt5UUmZGb2UJeuoklnkaKph7apq6k4MHFM8sCuLbN7IhVwjdG4Eha8iHKl M5V9n/W7gUAaMJPR9ZO4 =s1n7 -----END PGP SIGNATURE----- --YZQs1kEQY307C4ut--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121227184704.GK82219>