Slax author's Blog (RSS)

I can not wait to put my hands on it!!!

http://my.opera.com/gs2501/blog/2012/09/01/ahhh-iphone

Hi Tomas,

imho you should think about integrating zram into the 'Linux Live Kit'.

I am using it with fluxflux for memory constrained netbooks and was able to increase the ram amount used by the live scripts from 60% to 80% without any remarkable faults.


liblinuxlive(linuxkitlib):

...
# ==================================================================
# RAM compressing/optimizing function#s
# Author: Manfred Mueller, http://fluxflux.net
#
# Heavily based on zramswap-enabler from Sergey "Shnatsel" Davidoff,
# https://launchpad.net/~shnatsel
# ==================================================================

zram_start() {

# get the number of CPUs
num_cpus=$(cat /proc/cpuinfo | grep "cpu cores" | cut -d: -f2 | sed 's/ //g' | uniq)

# set decremented number of CPUs
decr_num_cpus=$(( $num_cpus - 1 ))

# get the amount of memory in the machine
mem_total_kb=$(grep MemTotal /proc/meminfo | rev | cut -d" " -f2 | rev)
mem_total=$((mem_total_kb * 1024))

# # determine modprobe parameter name, depending on kernel version
# if (uname --release | grep -E --silent "^3\.[123]"); then
# num_devices_parameter='zram_num_devices'
# else
# num_devices_parameter='num_devices'
# fi

# load zram modules
modprobe zram num_devices=$num_cpus

# initialize the devices, set total size to 1/2 RAM
for i in $(seq 0 $decr_num_cpus); do
echo $((mem_total / 2 / num_cpus)) > /sys/block/zram$i/disksize
done

# Creating swap filesystems
for i in $(seq 0 $decr_num_cpus); do
mkswap -L zram$i /dev/zram$i
done

# Switch the swaps on
for i in $(seq 0 $decr_num_cpus); do
swapon -p 100 /dev/zram$i
done
}

zram_stop() {

# Switching off swap
for i in $(grep -E --only-matching '/dev/zram[[:digit:]]+' /proc/swaps); do
swapoff $i
done

# remove module, wait instead of failing if it's busy
rmmod --wait zram
}
...

linuxrc:

...
# zram
if [ "$(cmdline_parameter zram)" != "" ]; then
if [ ! "$GERMAN_IS_ENABLED" ]; then
echolog "Using zram to increase usable RAM..."
else
echolog "Benutze zram zur Vergrößerung des nutzbaren Arbeitsspeichers..."
fi
fi

zram_start
...

RAMSIZE=$(cmdline_value ramsize)
if [ "$RAMSIZE" = "" ]; then
if [ ! "$(cmdline_parameter zram)" = "" ]; then
RAMSIZE="80%"
else
RAMSIZE="60%"
fi
fi
...


cleanup:

...
# kill all processes which can be killed
killall_unneeded $(pidof cleanup)

# zram
if [ "$(cmdline_parameter zram)" != ""]; then
if [ ! "$GERMAN_IS_ENABLED" ]; then
echolog "disabling zram..."
else
echolog "Deaktiviere zram..."
fi
fi

zram_stop

...


You will want to neglect the the translations ;)

Regards and best wishes for your work on the new Slax.

Quax

Thank you very much for your suggestion. I believe there are two possible methods of doing this, your method (zram) is one of them, actually it seems relatively complicated to setup. The other one is zcache. I'm not sure if it does exactly the same thing, so I will test it and write a blog post about it.

Zcache doesn't use block devices. Thus you can't use it for swap :(

In addition I have one more question regarding boot with future Live Kit:

Will you load gpu drivers from initrd?

On the one hand this will make X configuration easier and on the other you would achieve a consistent look with kms during boot.

Quax

Actually I thought that zcache (when enabled) does compress everything in memory automatically (including pagecache), without virtual swap files. But it seems I was mistaken, and your suggestion (zram), which I didn't know before, is the right way to go.

My tests show that disksize can be easily set to even 200% of current physical RAM, contrary to 50% used in your example. The more you use, the more you get compressed, thus the more you get free :)

Also I didn't fully understand why you need to setup several zram devices (one per processor), while a single zram device seems sufficient.

Regarding KMS, as far as I was reading about it few months ago, there was support only for some Intel and maybe ATI gfx drivers. If the situation didn't change, it seems useless to support some drivers and not others. To be honest, I'm considering full textual boot (as like old Slax), so consistent gfx look during boot is not top priority :)

One reason for using zram with one device less than total of cores simply was that I've tested it on an AMD X6 and wanted to achive some kind of balancing between the cores. The reason for using only 50% of ramsize was that I wanted to have some available ram if zram failed.

Regarding KMS:

Most actual X drivers (Intel, Ati, Nouveau) need KMS. Thus I think if you have disabled it in kernel config X wont be autoconfigured with the right screensize/modelines especially on wide screen net-/notebooks.

Integrating the modules in initrd would prevent the bootscreen running with another resolution than the running system.

Fanthom did a nice job with porteus by selecting the gpu driver to use via pciids in linuxrc.

I'm not sure at the moment if KMS is enabled in kernel or not, I didn't check. I'm using Slackware's kernel with only added AUFS to it, no other modifications.

Depending on the speed of the usb devices chances are that they get accessed too fast. Imho you should change the fatal message in linuxrc to try to append 'rootdelay=10' to the kernel line before copying Slax to harddisc.

This kernel append fixed most of the usb related boot errors with fluxflux in the past.

I'm not sure if I understand. rootdelay is meant as a timeout for kernel to wait until hard drives are visible before mounting root filesystem. This doesn't apply to LiveKit. The current approach (in the old Linux Live scritps) is to periodically check all visible drives once per second until the data is available (up to 10 times). This way, the data is mounted as soon as it is visible. So you say this is not sufficient? Maybe there should be 20 tries (max 20 seconds)?

I hope you understand - it is better to check once evey 1 second while waiting, instead of blindly sleep 10, since the data may be available in second 3, thus it would sleep 7 seconds unnecessarily.

On the one hand I have to believe the serveral users posts in my forum, that 'rootdelay=10' helped in that special case.

On the other hand your explanation is logical...

Maybe you could integrate a cheatcode "poll=" to be able to increase drive polling in case of (very) slow usb drives/controllers?

Actually I can safely set the interval to do even 30 cycles, or 60 cycles ... since it won't wait 30 or 60 seconds - if data is found, it will continue immediately. I guess that for some hardware the default 10 cycles (meaning 10 seconds) was not enough, thus rootdelay=10 gave those users another 10 seconds plus. I would believe this too :) Thanks to your comment I'll increase the number of search-cycles to 60, that should not harm anybody :)

Fully text mode boot gets my vote, fwiw.

here is the list of cheatcodes introduced in Porteus which could be backported to Slax 7 or even 'linux Live Kit' for better user experience:

base_only
extramod=
fsck
kmap=
mopt
noautologin
noeject
nonetwork
norootcopy
vga_detect
volume=

pasting here full cheatcode descriptions makes no sense due to their size so please go to this website to get them (ofc - if you are interested):
http://porteus.org/info/docs/57-general-information/117-cheatcodes-what-they-are-and-how-to-use-them.html

additionally i'll say that extending 'from=' cheatcode with UUID/LABEL support may be very helpfull to the users.

Cheers

Hi Tomas, what about adding a link from the old website http://www.linux-live.org/ to the github page and vice versa? Just to promote its visibility.

And I am going to write a blog post (in Traditional Chinese) about the great news of slax revival!

Hope it will be easy again for me to duplicate "tux usb keys" as a service for the audience attending my talks in Taiwan. A usb key booted by slax can copy its running self to another (with my out-dated mk-boot-usb script) and life was much easier when slax was usable.

Cheers!

Good idea ckhung :) Thank you, will do so.