Being the hidden source of this discussion it's only fair to try to explain the origin. ;) First objective was to get rid of the swap partition: - we do not know upfront the amount of ram and the appropriate swap size for a particular SBC/system - being a hardware guy it does not make sense to me to provide a sap partition while in realty data is written all over the medium (SD card) to level out wear. NOTE this is from my low level hardware perspective there may be compelling arguments from a (high level) system perspective. And yes the most commly offerd 1G is a little comes a little to short for us: We would love to offer a mail-server with antivirus capabilities utilizing Rspamd and ClamAV, and unfortunately CalmAV has a memory foot print of about 650 MB. You may argue this is not feasible. My vredo is you can't be sure before you tried and and squeeze every drop of performance out of out out ar boards. That's why compressed swap-space in memory came up the table. Reading on it got me convinced it's a solution wort to persuit and we are moving to it until proven faulty. here the kickstart files we currently using to make images: https://github.com/markVnl/nethserver-createimg/tree/ks_wip/ks Would love to benchmark; ie craft a test to get some numbers on the table Unfortunaly my knowlage comes to sort to provode this. What can say is my compile time of big demanding packages on a odroid HC1 drop about 20-25%; especially "linking" speeds up remarkable! How can we craft a test? -----Oorspronkelijk bericht----- Afzender: Robert Moskowitz<rgm at htt-consult.com> Verstuurd: Vrijdag 12 Oktober 2018 19:36 Aan: Conversations around CentOS on ARM hardware <arm-dev at centos.org>; Fred Gleason <fredg at paravelsystems.com> Onderwerp: Re: [Arm-dev] Using zram-swap On 10/12/18 1:24 PM, Fred Gleason wrote: On Oct 12, 2018, at 13:15, Gordan Bobic <gordan at redsleeve.org <mailto:gordan at redsleeve.org>> wrote: It depends on what you are running on that system. If you have 1GB of RAM and want to run a desktop environment web browser, that'll go pretty poorly without swap. So how does putting swap on RAM help that situation? You’re not increasing the overall memory space by doing so, but merely partitioning it into two different buckets (while also adding the complexity and performance overhead of accessing the part that is now ‘swap’). See Gordon's earlier comment on Firefox's bad memory allocation. Zram is a big help there; I see this on my F29 system. # free total used free shared buff/cache available Mem: 1022148 655520 107204 22284 259424 327636 Swap: 487304 253952 233352 # zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lz4 475.9M 246.4M 109.1M 114.2M 2 [SWAP] My mail server can be all over the place on memory and swap usage (it uses real swap file on sata) depending on what all the scanning software is doing and who is using roundcubemail. So YMMV, and this should not hurt if your system does not need to swap. # free total used free shared buff/cache available Mem: 2060396 189332 1189972 26432 681092 1766392 Swap: 982420 0 982420 # zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lz4 959.4M 4K 64B 4K 2 <swap> I may switch this setup to a Cubeboard2 (1GB mem) from the Cubietruck. I have a number of C2 and only a couple CT, so if it does not need the memory... Cheers! |----------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |----------------------------------------------------------------------| | A room without books is like a body without a soul. | | -- Cicero | |----------------------------------------------------------------------| _______________________________________________ Arm-dev mailing list Arm-dev at centos.org <mailto:Arm-dev at centos.org> https://lists.centos.org/mailman/listinfo/arm-dev <https://lists.centos.org/mailman/listinfo/arm-dev> _______________________________________________ Arm-dev mailing list Arm-dev at centos.org https://lists.centos.org/mailman/listinfo/arm-dev