Dear Norman, Thank you for the detailed explanation. I now have a clear plan to tackle this issue. Unfortunately, I had to re-prioritize and couldn't go down this path yet. Hence, my late reply.
Thank you. Sid On 2025-06-03 12:10, Norman Feske wrote: > Hi Sid, > > On 2025-05-27 08:24, Sid Hussmann via users wrote: >> I want to determine the total resources consumed within a deeply >> nested subsystem. The only apparent way to do this is to iterate >> through all the init state reports of the children and their >> ancestors down to the leaf and accumulate the respective `ram_used` >> and `caps_used` attributes of the `child` nodes. Is this the way? > >> Intuitively, the parent at the tree's root should be aware of this >> information. However, after digging through the documentation and the >> code, I found that this `total_ram_used`/`total_caps_used` >> information is not available out of the box within an init >> component/sandbox library. I assume the reason for this is that there >> is no (easy) way to communicate this information all the way back to >> the parent. > your intuition is right. The top-level init instance has in principle > all the strings in hand because it has created the PD sessions of all > children, grandchildren, etc. in the first place. E.g., when enabling > the reporting of the requested sessions via > > <report requested="yes"/> > > you can in fact observe all the PD sessions with their corresponding > labels. You can try this live at home on Sculpt OS by editing /config/ > managed/runtime in the inspect view and then looking at the resulting / > report/runtime/state. > > The labels reveal the component topology. What's missing from the report > is the live status of the 'ram' and 'caps' for the PD sessions. The > reported amounts show merely the session quotas (the quota donated at > session-creation time and via Parent::upgrade). But quota transferred > from one PD to another via 'Pd_account::transfer_quota' is not covered > because init is not involved in such transfers. > > However, since init has all the PD capabilities at hand, it could in > principle ask each PD for its live 'ram_quota' and 'used_ram' via the > corresponding RPCs. E.g., as a quick hack you could add such details to > the reporting at sandbox/child.cc [1] by inspecting the > session.service().name() for "PD" and then, once you know that the > session is a PD session, cast the corresponding 'Session_state::cap' to > a 'Capability<Pd_session>' (via 'static_cap_cast') and issue the RPC > call of interest. > > Note, however, that those RPCs are not for free. Depending on the > complexity of the scenario and the rate of reporting, the querying may > induce unwelcome overhead. > > [1] https://github.com/genodelabs/genode/blob/master/repos/os/src/lib/ > sandbox/child.cc#L425 > > An alternative way would be the wrapping of core's PD service as done by > the monitor component (look out for 'Inferior_pd'). The monitor thereby > sits in-between each monitored component and core's PD service. Hence, > it can observe all interactions including 'transfer_quota' between PDs. > >> Is my assumption correct that the only way to determine a subsystem's >> resource consumption is to aggregate the init state reports down to >> the leaf? > > The two approaches sketched above are preferable because one gets all > the information at a central point instead of relying on the good will > and the enabled reporting of all the nested init instances. > > In your position, I would try implementing the feature using the sandbox > API, taking inspiration from the monitor component. But your component > will be _much_ simpler. Like the monitor, you can then use your > component as a drop-in replacement of init. > > Cheers > Norman >
OpenPGP_0x4BC4E441F1068163.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ users mailing list -- users@lists.genode.org To unsubscribe send an email to users-le...@lists.genode.org Archived at https://lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/message/RN6X6LDTCMMLU5DA3X7CEPSOXUTLQXHQ/
