Hi Cedrik,
On 2024-01-17 09:42, Cedric At TTS via users wrote:
From my vantage point, I find that idea (on-demand fetch) quite intriguing. If I understand it correctly, it seems this concept would end up enriching the Genode API with yet another "forte" (strong point), the same way that things like RM, and the super modular vfs system, and many other things, empower us when writing code for Genode.
If I put on my 'syst. integrator' hat, when crafting my system to run Falkon I found myself wondering where to set the bar for the cached_fs_rom RAM quota, so that it would be neither 'too little' nor 'too big/wasteful'. The prospect of just setting it to a 'low' value like 200M and letting the Genode class handle where and when to load/unload disk data to respond to read requests is enticing. (it could even go the extra mile and allow the setting to be changeable dynamically, rather than statically set once and for all at startup time).
that's exactly my line of thinking. Personally, I encountered the limitation of the current implementation when using the MNT-Reform laptop with only 4 GiB of RAM. Once I start the Falkon browser, all the heavy-weight ROMs (Qt, WebEngine...) are loaded, inflating the depot_rom (cached_fs_rom) as expected. Now, when switching away from the browser (e.g., selecting another preset w/o Falkon), I want the depot_rom to deflate so that I can use the RAM otherwise. But this does not happen unless I do a full "un-use" "use" cycle of the Sculpt partition.
Both, the capping of RAM usage of depot_ram as well as the inflating/deflating can be realized with the lazy-loading / on-demand-eviction idea. Now, the devil of implementing it lies in the details (sensible eviction strategies, async fs access, granularity of I/O), for which reason I don't want to hasten it.
P.S. As a (quite marginal) secondary point, that hypothetical new infrastructure might also help in my future/long term project to port the Hpkg package format to Genode (i.e. the don't-extract-contents-to-disk-but-uncompress-on-the-fly-to-ram-instead virtual FS concept that I've grown addicted to since the mid-2000s).
I love how you draw so many connections between our low-level ideas and your use cases when wearing the Haiku-hat (guessing you are a hat person?). :)
Cheers Norman