From systemd's source codes (src/oom/oomd-manager.h):
/* Take action if 10s of memory pressure > 60 for more than 30s. We use
the "full" value from PSI so this is the
* percentage of time all tasks were delayed (i.e. unproductive).
* Generally 60 or higher might be acceptable for something like
system.slice with no memory.high set; processes in
* system.slice are assumed to be less latency sensitive. */
#define DEFAULT_MEM_PRESSURE_DURATION_USEC (30 * USEC_PER_SEC)
#define DEFAULT_MEM_PRESSURE_LIMIT_PERCENT 60
#define DEFAULT_SWAP_USED_LIMIT_PERCENT 90
So I guess using something lower than 60% * 1,000,000 would be OK (e.g.,
200,000).
Regards,
Qi
On 11/29/23 17:21, Robert P. J. Day wrote:
a colleague is using Wind River Linux and is getting occasional OOM
errors when taking advantage of maximum parallelism, so he took the
quick way out and dialed things back using BB_NUMBER_THREADS and
PARALLEL_MAKE.
however, i am aware of the bitbake variables
BB_PRESSURE_MAX_{IO,CPU,MEMORY} and was wondering if there is a decent
writeup on how to use, perhaps, BB_PRESSURE_MAX_MEMORY, to dynamically
detect imminent OOM and adjust things. that is, how to calculate a
sane value for that as i haven't yet dug into the values under
/proc/pressure and how to interpret them?
i've seen mentions of combining the above with the "memstat"
command, and other approaches. thoughts?
rday
p.s. is there a docs page that expands on this stuff?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61772): https://lists.yoctoproject.org/g/yocto/message/61772
Mute This Topic: https://lists.yoctoproject.org/mt/102868689/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
