RFR(S) 8186770: NMT: Report metadata information in NMT summary
adinn at redhat.com
Tue Sep 5 15:18:40 UTC 2017
On 29/08/17 17:31, Zhengyu Gu wrote:
> Okay, I see what you mean. But in this case, capacity = committed.
Well, it does not always seem to be exactly the same. If you add up all
the pieces to derive the capacity then it sometimes seems to fall short
of committed. I looked deeper into this and found that sometimes the
difference is down to rounding up/down. However, there also seems
occasionally to be more space unaccounted for that cannot be explained
by rounding errors.
I looked into your suggestion that this might be accounted for by 'dark
matter' i.e. tail ends of a chunk left unused when the last block is
carved out and the chunk retired because the tail is too small to insert
into the block dictionary. However, from my reading of the code I think
that any such 'dark matter' will still to show up in the waste space count.
Rather than hold up this current change I'd prefer to see it pushed and
address the arithmetic problem in a follow-up issue. Even with an
occasional small disparity in the reported figures I think it is really
helpful to have this detailed info available as part of the NMT output.
> I wonder if it is cleaner that just reports free, used and waste, e.g.
> ( Metadata: )
> ( reserved=22528KB, committed=21504KB)
> ( used=20654KB)
> ( free=786KBKB)
> ( waste=64KB =0.30%)
> where free = (capacity - used) + free_chunks + available
> waste = committed - capacity - free_chunks - available
> total = committed
Yes, I agree that it's ok to leave the available figure implicit -- it
is easily computed from the committed total by subtracting used and
waste (that's only correct modulo the occasional small disparity between
capacity and committed but the difference is small enough not to be
significant). So, I'm happy with this version.
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
More information about the hotspot-runtime-dev