Opened 5 years ago
Last modified 4 years ago
#14831 new bug
Optimize packagefs memory usage
Reported by: | s40in | Owned by: | bonefish |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | File Systems/packagefs | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | #10163 | |
Platform: | All |
Description (last modified by )
Haiku Beta1 consumes 262MB
When booted in unpacked version Beta1 consumes only 148MB
Which is almost 120MB less RAM.
See screenshots
Attachments (4)
Change History (16)
by , 5 years ago
Attachment: | Haiku unpacked mem.jpg added |
---|
by , 5 years ago
Attachment: | Haiku hpkg_mem.jpg added |
---|
comment:1 by , 5 years ago
Component: | File Systems → File Systems/packagefs |
---|---|
Description: | modified (diff) |
Keywords: | packagefs hpkg removed |
Owner: | changed from | to
Summary: | Packagefs memory leak → packagefs memory leak |
by , 5 years ago
Attachment: | Haiku hpkg.jpg added |
---|
by , 5 years ago
Attachment: | Haiku unpacked.jpg added |
---|
comment:2 by , 5 years ago
comment:3 by , 5 years ago
Summary: | packagefs memory leak → Optimize packagefs memory usage |
---|
follow-up: 6 comment:4 by , 5 years ago
Same thoughts here. Would be nice to investigate where this memory is going to, though, just to know. I find the difference acceptable in principle, at least.
BTW: How would I build a Haiku version without PM? That sounds interesting to improve the turn-around times when doing kernel development.
comment:5 by , 5 years ago
120MB is bloaty to the point of ridiculous though... even if it isn't a memory leak per se.
I assume this has something to do with how data structures that are needed to implement a single coherent filesystem out of all the packages are implemented... perhaps the packages themselves could restructured so that the data structures that are needed can just be mmaped directly from the hpkgs and leave the rest up to cache instead of actually loading things into memory. If it already does that then it seems there is some other problem...
Memory wasted to packagefs is memory you don't have for cache...it seems to make the installer unbootable on my 512MB system also (need to retest since beta).
I guess any shine through R/W files might cause overhead as well?
comment:6 by , 5 years ago
Replying to axeld:
BTW: How would I build a Haiku version without PM? That sounds interesting to improve the turn-around times when doing kernel development.
IIUC, you need to copy your /system folder to another bfs partition, delete everything in system/packages except for haiku_loader hpkg. I havn't tried it myself, tho.
comment:7 by , 5 years ago
After the O_NOCACHE change, is there any improvement here?
Also, what's the cached vs. used memory? (See ActivityMonitor.) We only really care about more "used" memory, "cached" memory usually can be reused.
comment:8 by , 5 years ago
Blocking: | 10163 added |
---|
comment:11 by , 4 years ago
As of hrev54509 on x86_64, here are the top consumers:
- 75 MiB app_server (one terminal window open)
- 70 MiB package_daemon
- 64 MiB Tracker
- 16 MiB 1x sshd connection
- several 1-2 MiB processes
~ 256 MiB of ram seems like the *absolute* bare minimum. ~ 384 MiB to avoid swapping running minimal applications ~ 512 MiB or more preferred
Haiku could be stripped down to run on < 128 MiB of RAM in theory if we could boot without app_server and tracker.
comment:12 by , 4 years ago
64MB for Tracker sounds very wrong, uses far less here (and elsewhere as seen in screenshots.) Same for app_server.
You also do not seem to account for kernel memory usage here which is far greater than userland in this case. packagefs is the largest consumer there, IIRC a sans-packagefs Haiku boots using 100MB+ less RAM.
I'm not sure that's a memory leak. packagefs seems to use a lot of memory for internal data structures; while this could be optimized, I don't know of any leaks here.