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