zram...? Raspberry Pi & Snakeoil

[Bromf]

zram vs swap.... seems easy to try and revert....
I don't think either are particularly needed as monitoring with top whilst playing seems to show the most hungry program being...top @14% CPU on one core.

Mpd is pretty low resource usage anyway and these days I am using an AK4137 re-sampler to convert to DSD256 either via xmos or I2S depending on player so no heavy re-sampling is needed by the o/s or player hardware and DSD is fed to an Ess DAC bypassing some of the Chip's filtering.

So, I will try some more listening tests using zram and see if I can notice any difference....
Any comments appreciated...

https://github.com/novaspirit/rpi_zram

[agent_kith]

zram vs swap.... seems easy to try and revert....
I don't think either are particularly needed as monitoring with top whilst playing seems to show the most hungry program being...top @14% CPU on one core.

Mpd is pretty low resource usage anyway and these days I am using an AK4137 re-sampler to convert to DSD256 either via xmos or I2S depending on player so no heavy re-sampling is needed by the o/s or player hardware and DSD is fed to an Ess DAC bypassing some of the Chip's filtering.

So, I will try some more listening tests using zram and see if I can notice any difference....
Any comments appreciated...

https://github.com/novaspirit/rpi_zram

swap is just there as a buffer in case my RESTful API messed up. So far it hasn't, but if it does at least there's something to fall back to. The good thing is if there's no issues, then the swap space will be enabled but not used. if you know what I mean.

An good  option is to have an option to turn off swap entirely. That may be worthwhile I think.

As for zram.. That's the first time I have heard of it.. Will try and research later what it is later on.

[Bromf]

zram is a 'swap' space in ram using compression. It replaces a conventional swap space so reduce wear/usage for the Pi's sd-card and is much faster if and when it is used.
The linked github version for the Pi removes current swap and replaces it with zram swap calculated for the performance/cores of a Pi3 or better.

I've found no performance issues so far in testing.... though no obvious benefits yet either...

https://www.kernel.org/doc/Documentation...v/zram.txt
https://www.cnx-software.com/2018/05/14/...able-zram/

[agent_kith]

zram is a 'swap' space in ram using compression. It replaces a conventional swap space so reduce wear/usage for the Pi's sd-card and is much faster if and when it is used.
The linked github version for the Pi removes current swap and replaces it with zram swap calculated for the performance/cores of a Pi3 or better.

I've found no performance issues so far in testing.... though no obvious benefits yet either...

Ah, that brings back memories back in the DOS days.. A memory compressor.

https://www.kernel.org/doc/Documentation...v/zram.txt
https://www.cnx-software.com/2018/05/14/...able-zram/

I'd see if I can get that support in. Chances are, it'd require a new kernel though.. Wiill explore this in time.

[Bromf]

From what I've read zram is merged into mainline kernel since 3.14....
Using the linked github install on RPi and when I run...

Code:

$ grep zram /proc/swaps

it returns...

Code:

/dev/zram0                              partition    236028    0    5

so appears to be enabled as default swap but unused currently as Pi3 and Snakeoil is using so very few resources..

[agent_kith]

From what I've read zram is merged into mainline kernel since 3.14....
Using the linked github install on RPi and when I run...

Code:

$ grep zram /proc/swaps

it returns...

Code:

/dev/zram0                              partition    236028    0    5

so appears to be enabled as default swap but unused currently as Pi3 and Snakeoil is using so very few resources..   

Run something intensive like JRiver and see more RAM gets consumed. To be fair this also likes a virtual desktop, hence the extra overheads. This is why I prefer MPD or LMS+Squeezelite.

Edit: To be even fairer I think I should be able to cut down the number of running processes too. From 1.x.x onwards I notice the number of processes running appear to be 2 to 4 times more than 0.1.x series. However, I guess because of the real time+force preemption kernel, it doesn't really matter as the process that requires CPU attention will always get it.

Hopefully I can revise the kernel and streamline it even more in the future.