Maximum number of modules and max_loop - are there limits?

Non release banter
User avatar
ahz
Black ninja
Black ninja
Posts: 42
Joined: 29 Dec 2010, 15:05
Location: Germany

Maximum number of modules and max_loop - are there limits?

Post#1 by ahz » 16 Jan 2012, 10:35

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.

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5666
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

Re: Maximum number of modules and max_loop - are there limit

Post#2 by fanthom » 16 Jan 2012, 12:30

/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.
Please add [Solved] to your thread title if the solution was found.

User avatar
ahz
Black ninja
Black ninja
Posts: 42
Joined: 29 Dec 2010, 15:05
Location: Germany

Re: Maximum number of modules and max_loop - are there limit

Post#3 by ahz » 16 Jan 2012, 14:59

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.

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5666
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

Re: Maximum number of modules and max_loop - are there limit

Post#4 by fanthom » 17 Jan 2012, 09:47

Please add [Solved] to your thread title if the solution was found.

User avatar
ahz
Black ninja
Black ninja
Posts: 42
Joined: 29 Dec 2010, 15:05
Location: Germany

Re: Maximum number of modules and max_loop - are there limit

Post#5 by ahz » 19 Jan 2012, 13:31

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.

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: Maximum number of modules and max_loop - are there limit

Post#6 by brokenman » 23 Jan 2012, 00:56

Hmmm .. another mark against uClibc.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
ahz
Black ninja
Black ninja
Posts: 42
Joined: 29 Dec 2010, 15:05
Location: Germany

Re: Maximum number of modules and max_loop - are there limit

Post#7 by ahz » 23 Jan 2012, 15:13

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.

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5666
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

Re: Maximum number of modules and max_loop - are there limit

Post#8 by fanthom » 24 Jan 2012, 12:48

@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.
Please add [Solved] to your thread title if the solution was found.

User avatar
ahz
Black ninja
Black ninja
Posts: 42
Joined: 29 Dec 2010, 15:05
Location: Germany

Re: Maximum number of modules and max_loop - are there limit

Post#9 by ahz » 24 Jan 2012, 13:34

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.

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5666
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

Re: Maximum number of modules and max_loop - are there limit

Post#10 by fanthom » 24 Jan 2012, 13:57

Please add [Solved] to your thread title if the solution was found.

User avatar
ahz
Black ninja
Black ninja
Posts: 42
Joined: 29 Dec 2010, 15:05
Location: Germany

Re: Maximum number of modules and max_loop - are there limit

Post#11 by ahz » 25 Jan 2012, 09:32

@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!!!

User avatar
wread
Module Guard
Module Guard
Posts: 1255
Joined: 09 Jan 2011, 18:48
Distribution: Porteus v5.0-kde-64 bits
Location: Santo Domingo
Contact:

Re: Maximum number of modules and max_loop - are there limit

Post#12 by wread » 25 Jan 2012, 12:16

@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.
Porteus is proud of the FASTEST KDE ever made.....(take akonadi, nepomuk and soprano out and you will have a decent OS).
The Porteus Community never sleeps!

User avatar
ahz
Black ninja
Black ninja
Posts: 42
Joined: 29 Dec 2010, 15:05
Location: Germany

Re: Maximum number of modules and max_loop - are there limit

Post#13 by ahz » 25 Jan 2012, 19:26

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.

Post Reply