From: Mikko Rapeli <mikko.rapeli@linaro.org>
To: Martin Jansa <Martin.Jansa@gmail.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
Yoann Congal <yoann.congal@smile.fr>,
MOHAMMED HASSAN <hassanchattarki@gmail.com>,
yocto@lists.yoctoproject.org
Subject: Re: [yocto] Memory requirements for building images with different architectures
Date: Fri, 8 Sep 2023 11:51:23 +0300 [thread overview]
Message-ID: <ZPrgi+npm5MBZ6QC@nuoska> (raw)
In-Reply-To: <CA+chaQfrtYAJTAkm8VDJFG4E0uQHZR6Uho0H3HZBOgH7nOLLoQ@mail.gmail.com>
Hi,
One related improvement is to avoid IO to disk completely as long as RAM is
available. By default file systems like ext4 will start writing all buffers
in the background after few seconds which is wasted IO if memory is available and
rm_work will anyway wipe the tmp to produce a target filesystem image tar ball etc.
sysctl settings are:
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 90
vm.dirty_expire_centisecs = 4320000
vm.dirtytime_expire_seconds = 432000
vm.dirty_bytes = 0
vm.dirty_ratio = 60
vm.dirty_writeback_centisecs = 0
http://events17.linuxfoundation.org/sites/events/files/slides/elce-2016-mario-goulart-mikko-rapeli.pdf
It the best case in-memory file systems like tmpfs will do but it's hard to estimate
the disk usage and memory size beforehand. Overflowing to disk IO only if RAM is
getting full scales better.
It makes sense to monitor build system CPU, memory, disk and network usage while builds are on
going. A lot of odd things will pop up, like IO bottlenecks (most CPUs idle), suprising network
downloads.
And deleting files is a heavy operation and if flushed to disk, it's annoyingly slow
compared to wiping an entire partition and creating a new file system on it.
Cheers,
-Mikko
next prev parent reply other threads:[~2023-09-08 8:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-08 5:02 Memory requirements for building images with different architectures MOHAMMED HASSAN
2023-09-08 5:12 ` [yocto] " Michael Opdenacker
2023-09-08 6:01 ` MOHAMMED HASSAN
2023-09-08 6:41 ` [yocto] " Yoann CONGAL
2023-09-08 7:06 ` Martin Jansa
2023-09-08 7:18 ` MOHAMMED HASSAN
2023-09-08 7:21 ` [yocto] " Leon Woestenberg
2023-09-08 7:20 ` Alexandre Belloni
2023-09-08 8:15 ` Martin Jansa
2023-09-08 8:47 ` Leon Woestenberg
2023-09-08 8:51 ` Mikko Rapeli [this message]
2023-09-08 10:58 ` Martin Jansa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZPrgi+npm5MBZ6QC@nuoska \
--to=mikko.rapeli@linaro.org \
--cc=Martin.Jansa@gmail.com \
--cc=alexandre.belloni@bootlin.com \
--cc=hassanchattarki@gmail.com \
--cc=yoann.congal@smile.fr \
--cc=yocto@lists.yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.