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@xxxxxxxxxx: 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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list