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

--
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth


_______________________________________________
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users

Reply via email to