Maximum number of modules and max_loop - are there limits?

[ahz]

As an addition to the existing FAQ it would be nice to know how many modules one can have within Porteus. Can this be pointed out? I came about this by using the max_loop ceatcode. What is his upper limit? You can read examples where it is 256. But can you use larger values too? Does the example max_loop=150 in the FAQ mean, that 150 is the maximum or should it be read as: If you use 150 then you can not increase it afterwards for this session.

[fanthom]

/boot/dosc/cheatcodes.txt says:

'max_loop=150' will give you 150 loop devices at startup,
but this number is hardcoded into the kernel and you wont be
able to create more.

this is actually wrong as i have started Porteus with 'max_loop=150' and still was able to add new loop devices with mknod command. maybe this was changed in latest kernel? not sure...
(Ahau - please remove "but this number is hardcoded into the kernel and you wont be able to create more." part)

it would be nice to know how many modules one can have within Porteus.

Aufs is set support up to 511 branches so theoretically you could use 511 modules. However - i have found that initrd is not able to handle more than 256 modules and this is an uClibc limitation. I have found this few weeks ago when number of modules in official repo (i have a local copy on my PC) crossed 256 number. i have solved this issue by using initrd from porteus-1.0 (compiled against glibc and not uClibc) with few tweaks. i can provide this tweaked initrd for ones who need support for 511 modules but i must mention one thing first:
from my experience i can say that porteus works noticeably slower when large number of modules is activated.
running 'slackyd -d' when 500 modules is activated almost kills system responsiveness.
this is because aufs must figure out which file belongs to which branch (module) and it takes extra CPU time.

i think 256 is the limit which we could stick with but it depends on users needs.

@all
please let me know if you need a support for more than 256 modules by default.

[ahz]

OK, actually I had 384 modules activated in Porteus 1.0 and that was no problem (with speed or stability). If I remove some garbage I could decrease the number to somewhat around 290 modules. I think that there are not much users with the need of such a large amount of modules. But anyway would it be nice to have the ability to go up to the aufs limit of 511 (so I am a candidate for the modified initrd :-). In either case this should be documented in the FAQ.

[fanthom]

here it is
32bit version:
http://ponce.cc/porteus/i486/current/ex ... in_initrd/
64bit version:
http://ponce.cc/porteus/x86_64/current/ ... in_initrd/

have fun

[ahz]

Thanks fantom, will try it the next days. Unfortunally I had problems to access www.porteus.org yesterday so this reply is a little late.

[brokenman]

Hmmm .. another mark against uClibc.

[ahz]

OK, could test it today. The "extended" initrd.xz doesn't work together with vga-detect. If I use the "standard" initrd.xz then vga-detect selects the nvidia driver, if I exchange it with the "extended" one nothing happens and nouveau is loaded.

[fanthom]

@brokenman
im still not done with uClibc
finally got extlinux compiled against it (60KB instead of 260KB) which let us get rid of syslinux (extlinux supports FAT just fine).
more details in first "realtime changelog" for porteus-2.0

i have opened a ticket for 256 loop devices limit on uClibc development mailing list:
http://lists.uclibc.org/pipermail/uclib ... 46324.html
hopefully will be sorted for the time of Porteus-2.0

@ahz
probably i have mixed up linuxrc versions. will check that once back home.

Posted after 18 hours 44 minutes 32 seconds:

@ahz
i have forgotten to add 'lspci' symlink inside initrd.
fixed now so please download once again.

[ahz]

Thanks fanthom,

the new initrd.xz detects now correctly nvidia or ati chipsets but fails loading the nvidia-module or ati-module: If I select "KDE vga-detect" all 300+ modules are loaded but KDE will not start. Instead I see the console login. No nv-module is loaded (as verified with lsmod). Doing so by hand (modprobe nvidia) I get the following error mssage:

FATAL: Error inserting nvidia (/lib/modules/3.1.8-porteus/kernel/drivers/video/nvidia.ko): Cannot allocate memory

I use ramdisk_size=6666 as cheatcode like it is described in README.txt.

[fanthom]

@ahz
http://porteus.org/faq.html#18

[ahz]

@fanthom: You are right. I sorted this cheatcode out last week and forget to put it back in. Now all works as expected (>300 modules with the new initrd.xz, nvidia and ati autoselect). Should the nvidia thread now be marked as solved? Thanks for your help!!!

[wread]

@all
Do the modules in "optional" make use of loop-devices when they are not activated?

If so, I don't know what's the use of having so many (over 256) loop-devices. One can have all the programs that are not used regularly in "optional" instead of "modules", and activate them when needed simply by clicking on it!

If increasing the number of loop-devices makes the machine slower, then better let it be...We cannot have the cake and eat it!

Regards.

[ahz]

I agree with you that you can store all not regulary used modules in optional and activate them by need. This makes sense, when you are the only person who uses "your Porteus" and you know exactly what modules you have and what they are doing. But if you want to give your "own Porteus" to other peoples things start getting complicated. Other users expect that things work "right out of the box". My experience showed me, that the e.g. activation of modules is difficult for Linux beginners (besides copying new modules to optional and the difference between optional and modules folder ...). New Linux users should preferrably learn how to work with it and not being frustrated by fiddling around with modules. What I have seen is, that there are always people who are technically interested and those learn very fast how to modify Porteus (by the way: Thanks to Ahau for the great documentation work)
This is why in my case I favour the possibilty of loading many modules. Currently I have 300+ modules in use and at the moment I do not see any significant speed decreases. At the moment it looks like that 300-400 modules are fitting all my needs. They are on a 32 GB memory card and about 24 GB of this card is in use are used.