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
