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