On 03/10/2014 08:10 AM, Daniel P. Berrange wrote:
If we were to keep the global log buffer pretty much none of this patch series is worthwhile, because as long as the global log buffer exists the other performance improvements in this patch are dwarved by the printf. Just minimizing malloc/printf overhead might let you cut overhead in 1/2 or even in 1/4, but that still leaves massive overhead behind. This patch series is reducing the execution time in the test program from 1 minute 40 secs, to 3 secs.
I don't see any optimization of printf/malloc being able to get us anywhere near this kind of level of improvement.
I agree that killing the printfs into the ring buffer makes sense - just waiting for anyone else to express an opinion.
We may not be dumping the ring buffer any more, but I _still_ think it's worth keeping this signal handler and dumping a message that we detected a fatal crash, as well as pointing the user to go read the contents of the logging files (and/or rerun libvirtd with more logging enabled). In other words, delete the ring buffer, but DON'T delete this last-ditch message to the user.
But if you don't install any SEGV signal handler, the kernel/glibc default will already print
Segmentation fault (core dumped)
So what more would libvirt do ?
Print a nicer message, something like: Fatal signal detected; please report this bug to libvir-list@redhat.com: Segmentation fault
I'm open to suggestions of what else libvirt could usefully (& safely) add to this, but I couldn't think of anything worthwhile.
Bug reporting address is nice. Backtrace would be useful, but hard to prove that it would work safely, and may be non-portable outside of linux). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org