Hi Cesare, sorry for the slow response, comments embedded. Am Monday 09 January 2012 schrieb Cesare Leonardi: > On 07/01/2012 18:48, Rainer Dorsch wrote: > > I recently setup zram (for compressed swap space in RAM) on an older low > > RAM machine. I was quite happy with the result and started now to do the > > same setup also on my other machines. I am wondering if anybody is > > investigating, if debian should do that by default when installing a new > > machine or even better also when machines get upgraded. > > Hi Rainer. > > What do you mean saying that you are happy with the result? In what > aspects? see below... > I ask you because while i'm skeptical too in wasting ram for swap, i > think i'll give zram a try to see the effects on responsiveness of > dormant application. > > Let me explain. > There is something that i find annoying in the default kernel setup and > is its tendency to swap out to disk even when there are plenty free ram. > So if you have an open application that you leave dormant while doing > other things (that app could be also the Gnome menu, for example), when > you'll need that you'll find a strange lag and unusual disk work. The > system is swapping even if the ram is about 50% free! > > So, in the past, i've modified the kernel setting with vm.swappiness=0 > (from the default=60). > Now it's better but not sufficient to avoid swap: for example today, > with an uptime of about 8 hours without suspend to ram or to disk, i > have 47 MB of used swap. And i see its effect as lag when i want to > restore from the screen saver or when i use the applet to change display > brightness, and so on. > > I'm almost sure that there is some other parameter that i could change > to avoid that preventive swap. In the past i've done some searches but i > found that was not so easy, as some other related parameters had to be > used with care. So i gave up. > And i also know it's a debated area, where different points of view > apply: IIRC Andrew Morton is one that is for vm.swappiness=100, to > minimize wasting ram from least used applications, that are moved to the > swap quite fastly. Probably if you have a super fast SSD the swap is not > so perceptible. > > So, returning to zram, maybe have you seen good result from a > responsiveness point of view? On one system, that is exactly, that is what I observe. Before disk swap was always used, now I have never seen that disk swap is ever used in this system: I posted this before: blackbox:~# swapon -s Filename Type Size Used Priority /dev/sdd partition 3910652 0 -1 /dev/zram0 partition 2070080 6360 100 /dev/zram1 partition 2070080 6388 100 blackbox:~# And certainly accessing zram is faster than accessing swap hdd. I do not see delays due to swap access anymore on my desktop.....this was in particular visible, since I migrated to an SSD on that system (and left swap on a frequently spin down hdd). The other system is a low end system with 512 MB RAM and it is running KDE4. With zram the system is much more responsive than just with HDD swap space. > In fact the point that i find interesting with zram is that, if you have > plenty of free ram, you can use it as a swap area for the data that, on > average on your desktop pc, the kernel will usually swap out (in my case > always < 100 MB). I guess that could have a positive impact on > responsiveness of the least used processes. > > Now, the best solution would be to tweak the right kernel parameters to > make it swap in a way i like more, rather than this hack. And the bad > opinion expressed so far make me more pessimist. > > By the way, i'll give it a try. ;-) Let us know what is the outcome. I think it would be good if we would have quantitative benchmarks....next time, when I have access to the low end system myself, I could try to measure boot time + KDE login time + Iceweasel start time + digikam start time + libreoffice start time + shutdown time or something like that with and without zram.... It certainly does not measure responsiveness, but I hope that avoiding hdd swap space gives a total speedup.... Thanks, Rainer -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: rdorsch@web.de jabber: rdorsch@jabber.org GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/
Attachment:
signature.asc
Description: This is a digitally signed message part.