Hi, we are just testing Torizon OS (TorizonCore Upstream 6.7.0+build.18) on an apalis-imx6 with 1GB Ram and 4GB flash.
We are using VS Code with the Torizon templates. The memroy usage seems high and the need for storage space alos seem tob e very lagre. For example if we are running only the Torizon Image on the device, the meory usage is at approx 40% (400MB). If the the Docker service is deactivatet, it is still at 30%. Also the sorage usage is araund 30%.
If we are now using for example the Avalonia template and create a very small application. Now the memory usage is up to 65% (650mb) and over 2GB of storage space is occupied. Which seems both very high. We also tested the templates for UNO (no Debugging for imx6!?) and Qt with alsmost the same effects.
Are these values normal? Are there optimizations possible?
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Based on the context provided, the memory and storage usage you are observing with Torizon OS on the Apalis iMX6 does seem to be on the higher side, especially when compared to your previous experience with WinCE boards. Here are a few points and potential optimizations to consider:
Base Memory Usage: The base memory usage of 40% (400MB) for Torizon OS is relatively typical, as Torizon is a full Linux-based OS with additional services and features that naturally consume more resources than a more minimal OS like WinCE.
Docker Overhead: Docker does introduce some overhead, which is why you see a reduction in memory usage when Docker is deactivated. However, Docker is integral to Torizon’s functionality, so completely removing it may not be feasible.
Avalonia and Other Templates: The increase in memory and storage usage when using the Avalonia template or other similar templates is expected due to the additional libraries and runtime environments required by these frameworks. Avalonia, being a cross-platform UI framework, can be resource-intensive.
Optimizations:
Minimize Running Services: Review and disable any unnecessary services or containers that may be running by default.
Optimize Docker Images: Ensure that your Docker images are as lean as possible. Remove unnecessary packages and dependencies.
Use Lightweight Frameworks: If possible, consider using more lightweight frameworks or libraries that better fit the resource constraints of your hardware.
Memory Management: While you mentioned that changing the CMA settings had minimal impact, continue to explore other kernel parameters or memory management techniques that might help.
Hardware Considerations: If resource constraints continue to be a significant issue, you may need to consider hardware with more RAM and storage, despite the cost implications.
Ultimately, while some of the resource usage is inherent to the nature of Torizon and the frameworks being used, careful optimization of your applications and system configuration can help mitigate these issues.
Please, also check if these links can help you solve your problem:
The memory usage you see is normal for Torizon OS.
For most applications this is not a problem.
However, it is always important to keep an eye on it and make sure that your application can run without issues.
There are optimizations that can be done on the container and application side to reduce the memory consumption.
One example that may be possible, depending on your GUI framework of choice, is to not use the Weston compositor container, instead opting to output directly to DRM.
Regarding the storage usage, when developing with the extension it is expected to be disproportionately high.
The reason for this is that during development a debug container is used, which includes debug symbols and libraries, increasing a lot the final size of the container.
When you generate a production image through the extension, it should be considerably smaller, and you should be able to further optimize its size by not adding unused packages and much more.
Optimizing containers for size is something that can be done in many different ways, so if needed there is usually a lot of room for improvement.
Do you have some idea of how much your application may require in terms of free memory and storage?
