lubuntu-qa team mailing list archive

[Leszek Lesner <leszek.lesner@xxxxxx>]

Am 28.09.2013 12:28, schrieb Joyce MARKOLL:
> On Sat, 28 Sep 2013 11:58:37 +0200
> Jörn Schönyan <joern.schoenyan@xxxxxx> wrote:
>
>> Am 28.09.2013 11:31, schrieb Leszek Lesner:
>>> Am 28.09.2013 11:03, schrieb Jörn Schönyan:
>>>> There are freezes with ZRAM in Precise, too. I experience this both 
>>>> with original stack/kernel and the enablement stack from Raring. 
>>>> Sometimes while shutting down, sometimes after a long session or when 
>>>> the RAM is "full". After disabling ZRAM, there are no problems at all.
>>> As far as I know the Precise kernel is 3.2 so it should not be 
>>> affected by the problem currently introduced by the 3.10.6 kernel. The 
>>> same goes for raring which uses the 3.8 kernel. And I hope the ubuntu 
>>> kernel devs did not port over the broken zram module from 3.10.6 to 
>>> the raring kernel.
>>> So there only might be two possibilities:
>>> 1. Its another bug.
>>> 2. Its not really freezing but just writing a whole lot of chunks to 
>>> zram which causes the cpu to run at 100 % for a long time and making 
>>> system usage unusable until the chunk is written to zram.
>> I am not 100 percent sure, as it is not my own machine :-/ myself, I 
>> haven't seen the freezes.
>>> The second thing can happen when lots of memory needs to be compressed 
>>> into ram and the cpu is not the fastest (single core for example). So 
>>> basically more than 60% of ram needs to be compressed. This takes a 
>>> longer time then and maybe halt user input for the time being.
>>> So it would help if you could verify if thats the case for you and if 
>>> it still halts when you give it some time to work. (not more than 10 
>>> mins please :) If this is really the case there are ways to limit the 
>>> ram that is available for compression (so limit it to 40% for example) 
>>> or even tweak the swapping setting to set how big the chunks should be 
>>> that are written to swap. (swap in this case made available from zram)
>> The owner waited at least 5 minutes, if it will unfreeze. The notebook 
>> is quite old, a Pentium M if I remember correct. It has 512 MB RAM and a 
>> VIA graphics card which I first suspected to cause the freeze :-)
>
>>> Also in rare occoasions(so if you only have 1 GB RAM and zram only 
>>> gives you 250 MB of swapspace and you need more) it might be useful to 
>>> use zram in combination with swap space on harddrive. So it would than 
>>> first swap out to zram until its full and then write to swap on hd.
>>> As for the shutdown issue this is exactly where it might come to an 
>>> hold for some seconds as it needs to clean zram (swap space by zram is 
>>> basically unmounted and the contents is written back to ram by swapd 
>>> or at least it is trying to write as much as possible back to ram)
>> Could be - I've set up a swap partition with 1,5 GB so this should in 
>> theory not be an issue.
>>
>> Jörn
> Hi,
>
> I have said what follows in other posts on this list lately, however I will repeat it:
>
> I have used zram in Ubuntu 12 as well as in the present Lubuntu Saucy testing and I don't
> meet with any freeze : I suspect your kernel(s) want to swap to disk which does cause
> freezes.
>
> Last year I installed antiX (based on Debian testing) on a very very old machine, HP
> Omnibus with 192 MB ram and a 800 Mhz celeron processor : I had to configure the
> swappiness to prevent the kernel from swapping to disk. Once done the zram module (and
> the associated scripts) did a very good job.
>
> Could you try where your distributions do "freeze" to ask the kernel to not swap to disk?
> Here is a configuration file:
> http://meets.free.fr/Downloads/BentoVillageProject/Configurations/System/etc/sysctl.d/50-local.conf
This is no real solution it is more of a workaround if you only have
workloads that don't go higher than the actual physical memory on your
computer. But if it goes higher than that all hell breaks loose &  the
system becomes unusable as it starts swapping out like crazy.
We tested such scenario in neptune with sysctl tweaks and especially a
config like you suggest. It only works fine as long it does not start
swapping. We messured that it is necessary to have around 250 mb to keep
the desktop (in our case KDE Plasma) and applications alive(keeping the
mouspointer responsive and clicking on apps does not cause a long halt
until the system reacts). This might vary for LXDE as it tends to use a
lot less for the desktop but I can't say it for sure as I never tested
this.


> Else, I configure 20% or 25% max in the initramfs.conf file (under /etc/initramfs-tools)
> ie: COMPCACHE_SIZE="20%"
>
> (I have explained in another thread that 50%, which is the default in Ubuntu for a reason
> which is unknown to me, might take too much from the CPU... and the above configuration
> is what I have been using in several distributions since several years with success, as
> well as a few dozens of users whom I provided with remixes having this setup).
Compcache is deprecated as far as I know so this config should not have
any effect. To reduce the zram swap space you need edit it in
/etc/init.d/zram-config . Be carefull there as it does not list it up as
percentage or so but it uses a shell script approach to calculate
physical ram available / 2 . Its not that trivial to change that as
shell script calculation does not support floats.
>
> Let me also add a word about the swap to disk : it is highly desirable to avoid swapping
> to disk, because it is very slow compared to swap to ram and therefore likely to trigger
> freezes.
>
>
A combination of zram and disk swapping with the priority to zram might
be better as only using zram when facing very low ram and very low zram
availability.