ramzswap and shutdown

[gerald_clark]

Please tell us what version you are running, and show the output of 'free'.

[TaoTePuh]

Please tell us what version you are running ...

3.5.1

... and show the output of 'free'.

Code: [Select]

tc@box:~$ free
             total         used         free       shared      buffers
Mem:       1033536       899348       134188            0        49880
-/+ buffers:             849468       184068
Swap:      2354844            0      2354844


tc@box:~$ cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/ramzswap0                          partition       258372  0       -1
/dev/sda2                               partition       2096472 0       -2


[gerald_clark]

Why are you running ramzswap when you have real swap?

[TaoTePuh]

hihihi, that was my next question ... 

ramzswap is a TC default ... I used it because it's there ... sorry, I'm just beginning to understand this all ...

The questions I have now are:

1.) Is ramzswap faster/better than a swap partition, although it must be compressed?
2.) If so, how do you calculate the size?

[gerald_clark]

ramzswap is dynamically sized compressed swap in RAM.
It uses some RAM to hopefully provide more RAM via compressing as it swaps out.

If you have real swap, turn it off.
If you have a RAM problem, you may get kernel panics when it tries to swap back in.
I would run memtest86 overnight.

[TaoTePuh]

If you have real swap, turn it off.

Turn off ramzswap or the swap partition ?

If you have a RAM problem, you may get kernel panics when it tries to swap back in.
I would run memtest86 overnight.

I don't think that there is something wrong with the RAM - but here are some new information after more tests:

1) I can reduce the problem to ramzswap. With the following scenario, the notebook definitely crashes:

Code: [Select]

tc@box:~$ tce-load -i stress
/mnt/sda3/tce/optional/stress.tcz: OK

tc@box:~$ stress --cpu 8 --io 4 --vm 2 --hdd 1 --timeout 10s
stress: info: [6862] dispatching hogs: 8 cpu, 4 io, 2 vm, 1 hdd
stress: info: [6862] successful run completed in 10s

tc@box:~$ free
             total         used         free       shared      buffers
Mem:       1033536       219984       813552            0         5704
-/+ buffers:             214280       819256
Swap:      2354844        33624      2321220

tc@box:~$ cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/ramzswap0                          partition       258372  33624   -1
/dev/sda2                               partition       2096472 0       -2

tc@box:~$ sudo swapoff /dev/ramzswap0
But if I turn off ACPI (boot code acpi=off), the computer does not crash with this scenario.

[gerald_clark]

That may be a BIOS problem.
See if there is an update.

I meant to turn off ramzswap.
If you are just short of RAM, swapping to RAM makes little sense if you have real disk swap.

[tinypoodle]

IIRC, you have complained about bugginess with ACPI before, is that the same machine?

IMHO, if acpi on or off under certain circumstances could make the difference between a kernel panic or not, I would not boot with acpi at all.
Exception would be after a BIOS update as gerald_clark suggested, or when changing kernel to a different version.

[curaga]

Actually, ramzswap is often useful even if one has real swap. If the ramzswap doesn't get full (and so the swapping continues to the next device) the responsiveness is hugely better than with disk-based swap only.

But the fact ACPI affects things makes me wonder where the blame really is.

[gerald_clark]

Which is why I said "just short of RAM".

Many times dormant processes are swapped out to make room for
more processes and buffers.
Swapping these out to real HD frees up more RAM than swapping to ramzswap.
Thus you may see that some swap is in use, but the machine is not actively swapping.

[TaoTePuh]

IIRC, you have complained about bugginess with ACPI before, is that the same machine?

Yes, this is the machine (Toshiba Satellite M60-139) of which I reported in
http://forum.tinycorelinux.net/index.php?topic=8981.0

BTW: The machine works perfectly. I use it every day for several hours with Firefox, Thunderbird, LibreOffice, freemind, gimp2, remmina, geany, vlc, FoxitReader ... - and all at the same time ... The only problem I have is: "shutdown" (Note: often needed from remote).

IMHO, if acpi on or off under certain circumstances could make the difference between a kernel panic or not, I would not boot with acpi at all.

hmm, this is a Catch-22 situation:
1.) I can not shutdown the machine without ACPI
2.) If I enable ACPI, I can not shutdown the machine if I used ramzswap during work

And thus the conclusion is:
a.) with functionality in mind: "disable ramzswap"
b.) with performance in mind: "disable ACPI"

Exception would be after a BIOS update as gerald_clark suggested, or when changing kernel to a different version.

There is no BIOS update for this machine.

Actually, ramzswap is often useful even if one has real swap. If the ramzswap doesn't get full (and so the swapping continues to the next device) the responsiveness is hugely better than with disk-based swap only.

That's how I understood it. I found a comparison "Comparing swap I/O latencies for hard-disk and ramzswap. " in the compcache Wiki with this results:

Comparing average R/W times:

        disk     ramzswap
read    168 ms   12 us
write   355 ms    7 us


These are factors between 14.000 and 50.000!

BTW: I also found a similar issue in the Bug Tracker of the compache site: "Swapoff ramzswap0 hard freezes system if utilized"
http://code.google.com/p/compcache/issues/detail?id=41&can=1

... unfortunately without a solution ...

But the fact ACPI affects things makes me wonder where the blame really is.

Me too.


But back to my general questions about ramzswap : "When does ramzswap make sense and how much RAM I use for it?"

Are the following thoughts right?

1.) RAM is much faster than ramzswap is much faster than swap paatition is much faster than file swaping.

2.) Optimal scenarios are:

a.) No or seldom need for swap --> disable ramzswap because it occupies valuable RAM.

b.) If swap is needed --> allocate as little as possible ramzswap so that as much as possible valuable RAM is available. The typical usage of ramzswap should lie at XX%.

In any case: To prevent system crashes, you should have additional partition- or file swap (fallback).

[gerald_clark]

To swapoff, you would probably need more RAM than you have.
The blocks would have to be uncompressed and copied to real RAM before they
could be freed.
The solution may be to simply NOT swapoff during shutdown.

[TaoTePuh]

This is really a good idea!

But how can I achieve this? poweroff is an exe-file and I can not edit it. Maybe you mean the Option -f  (Force (don't go through init)):

• sync
• /usr/bin/filetool.sh -b -s -p
• sudo poweroff -f

Is this method safe?

Edit: Okay, -f works. Wow, so fast my computer was never turned off ... But what important (shutdown) things are not happening with this method?

Edit2: hey, hey, hey ... i have edit the file "/etc/init.d/rc.shutdown". I commented out the following lines:

Code: [Select]

#if ! grep -q "noswap" /proc/cmdline; then
#   echo "${BLUE}Disabling swap space.${NORMAL}"
#   /sbin/swapoff -a 2>/dev/null
#fi

Now it works.

EDIT: Because it is not a good idea to edit the file /etc/init.d/rc.shutdown directly and put it in the backup (upgrade problems), here is an other solution which let the things done by the script /opt/bootlocal.sh at every boot time :

Code: [Select]

##
## disable swapoff command in /etc/init.d/rc.shutdown
##
# Search lines which contain "Disabling swap space" and place a notice
sed -i -r 's/Disabling swap space/Disabling swap space - WILL NOT BE EXECUTED/}' /etc/init.d/rc.shutdown
# Search lines which contain "swapoff -a" and.
# place a comment character at the beginning of those lines
sed -i -r '/^\s*#/!{/swapoff -a/s/(.*)/#\1/}' /etc/init.d/rc.shutdown


[tinypoodle]

Are the following thoughts right?

1.) RAM is much faster than ramzswap is much faster than swap paatition is much faster than file swaping.

Last part is wrong since several years. Would be true only after removing the "much" and only for =< Linux 2.4. and possibly very early 2.6

[curaga]

Last part is wrong since several years. Would be true only after removing the "much" and only for =< Linux 2.4. and possibly very early 2.6

While the kernel limits on that are no longer, it's still one abstraction layer more. Adding layers can't exactly increase speed