On 11/20/2013 01:09 PM, Viktor Mihajlovski wrote: > On 11/15/2013 07:41 PM, John Ferlan wrote: > >>> However I need to report an issue running on s390, cimprovagt >>> core dumps, so I need to investigate further and ask to >>> please hold off until I figure out the reason. Thanks! >>> >> >> I found investigating cimprovagt to be very painful, hence the reason >> why I redid 1-15 a bit. I'd suggest trying to apply 1-3 first - make >> sure they work. Then 4-13 to make sure they work. Then go slower on >> 14-20. I found that 14/15 were the most problematic... 16-18 were >> mechanical. 19 seemed to be harmless; however, who knows. > > well, it turns out that I was hitting a low memory condition, > maybe a side effect of patches, redoing the tests with more memory > worked well, which it should anyway because no "other" libvirt XML is > written back so far. So, no worries, especially as the patches are > under discussion anyway. >
That brings up an interesting test - how much memory is used by the current algorithm and how much gets used by the new algorithm... Not that there's a leak, I just think more memory is held onto than necessary. If each device has its own parse_data tree, then there's a lot of unnecessary duplication and even worse unused fields. Unfortunately when the data is then fetched - we don't add another pile of memory which isn't freed. At least this new code does a better job at failing on memory allocation compared to many other paths in the code... John _______________________________________________ Libvirt-cim mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvirt-cim
