In the file “dietpiEnv.txt” there is a variable which is by default “docker_optimizations=off” and I am wondering what it does and why one would want to leave it off or turn it on, what disadvantages there would be to having those optimizations on.
Based on this Best path to a custom kernel on arm? - #8 by multiblitz post it at least at that time set “cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1” at boot, but what disadvantages would there be to having those on?
Are there more things changed by that variable and if so, same query regarding those too.
@MichaIng Are you able to answer this question? My guess is that it has nothing to do with DietPi scripts, but rather with certain kernel functions on certain boards.
It enables the memory control group, Docker is adding itself to, which allows controlling and monitoring the amount of memory containers are allowed to use. Without this, Docker will throw some warnings on startup, other container engines even deny to start up. swapaccount=1 enables support for controlling swap space usage as well, basically completing memory usage control.
Probably the memory cgroup is in the meantime enabled OOTB as well. Theoretically, having those enabled means a tiny performance regression, hence they are/were not enabled OOTB. They are however enabled automatically, when you install any container engine via dietpi-software.
cgroup_memory=1 was an ancient RPi-only setting, replaced by cgroup_enable=memory, and has no effect anymore since years. No idea why this is still floating around. I am wondering about the cpuset control group. IIRC, on Armbian kernel, it was enabled OOTB, but on my RPi Zero W it is not enabled OOTB. But even that we do not actively enable it on container engine installs, those do not fail.
Aha.
Thank you very much for the detailed answer, @MichaIng!
It seems to me that setting in that file pretty much is pointless then, except in some extreme edge cases where those users would know to enable the specific flags that they need anyway.
Good to know.
Using Docker or other container engines is not such an extreme edge case. But as long as you do not use it, and no other software you use fails or complains to require the memory control group, there is no point to enable it, indeed.
