| Summary: | fstab should set tmpfs to 25% | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | David Turgeon <david.turgeon> |
| Component: | core | Assignee: | David Turgeon <david.turgeon> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | JPEWhacker, meta.mr.watcher, meta.watcher, randy.macleod |
| Version: | unspecified | ||
| Target Milestone: | 3.4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
|
Description
David Turgeon
2021-05-03 19:13:57 UTC
Can you provide a link to the man page and or quote it? The concern is that the default shared pool of RAM for tmpfs is up to 50%, is that a problem and if so why? https://linux.die.net/man/8/mount Override default maximum size of the filesystem. The size is given in bytes, and rounded up to entire pages. The default is half of the memory. The size parameter also accepts a suffix % to limit this tmpfs instance to that percentage of your physical RAM: the default, when neither size nor nr_blocks is specified, is size=50% I couldn't find anywhere in documentation saying this was shared. So I tried filling up both tmpfs and it showed that processes started to get killed by OOM. I never actually was able to fill both partitions before the system became inaccessible... Fair enough. However, I suspect it might cause problems with existing users to suddenly put a hard limit that is half what it used to be, so I think we need to leave this There are use cases where users write large files to the tmpfs with the understanding that they have "enough ram" to handle it (I know of several places that I'm doing the personally). For better or worse, lowering the default priority will break these use cases, so we shouldn't change it. |