Hi Roman,
How can I distinguish if the condition is handled properly or not? Are there any preceding or following log messages in either case?
I remember the following situations where the messages were somehow useful to diagnose a problem:
- If the scenario got stuck with the this being the last message. This happened in the phase when we introduced the dynamic resource handling originally (around version 13.11). In the meanwhile, we have equipped all places where clients may encounter the out-of- metadata condition with corresponding handlers (i.e., in the form of the 'base/src/include/base/internal/expanding_*_client.h' classes). Therefore, I haven't observed this effect for a long time now.
- If a component aborts right after a quota-exceeded message, this is a strong hint that an exception handler is missing. An example is the issue recently reported by Denis (and fixed with [1]) where core missed to reflect an 'Allocator::Out_of_memory' condition as an 'Rm_session::Out_of_metadata' exception. That said, in this case, the message does not add too much information because the abort message already prints the exception type, which should suffice to diagnose the problem.
- If an unusual amount of quota-exceeded messages appears, this hints at a resource leak or at least an opportunity for optimization. The initial session quotas and the quota upgrades are dimensioned such that the quota updates are needed only sporadically. If the log is flooded by quota-exceeded messages, a superficial number of quota upgrades is performed, which should better be investigated.
The more I think about it, the better I like the idea to remove the message. In the log, it gives a wrong impression of presumed problems where none exists because the quota upgrading is a normal part of life of Genode components. The diagnostic value added by the messages is indeed quite low.
[1] https://github.com/genodelabs/genode/commit/fac69eff48b3d70a9d37ebc5d3ae6746...
- Does the size of the metadata allocation for a child depends on whether I'm using a 32 or 64 bit system?Yes. I.e., your scenario produces the message only on 64 bit, not on 32 bit.
Is it worth thinking about calculating the slack memory size based on Genode::addr_t? Or make the value even configurable?
Making the value configurable seems to be the most sensible idea. I will respond to Ben's (Nobody III) posting with an explanation why.
Cheers Norman