VM Out of Memory; Kernel panic - not syncing: System is deadlocked on memory

[the_hopelessest]

Hi there,
I'm new to TC and the forum. Please excuse me if I got something wrong.

I'm trying to build a VM for test purposes with frugal install of TC and as little memory as possible.
I saw the requirements of 64 mb and recommendation of 128 mb, and I went for it, but with 128 the TinyCore-12.0.iso wouldn't boot. It says Out of Memory: killed (process name) and some extra info I don't really comprehend well ... and at the bottom:  Kernel panic - not syncing: System is deadlocked on memory. Adding up a bit more memory (to 164 mb) would make it boot well.
Then I realized I need 64 bit version (for the binary I need to run there is compiled against 64 bit cpu), so I went for CorePure64-12.0.iso. It needed even more: 256 mb to boot.
I played with several boot options, making opt and home persistent, used nozswap and tried adding a swapfile - no success lowering the memory.

I came across this post:
http://forum.tinycorelinux.net/index.php?topic=23905.0
and so I decided to use an older version (10.1 as suggested) but ... it didn't help either.

Please let me know what are the realistic minimum memory requirements for such a VM running TC frugal install and how I might achieve it on VMware VM.
Thanks in advance.

[curaga]

Software keeps getting bigger, and 64-bit software needs more RAM than 32-bit, that's unfortunately how it is. We haven't redone those measurements for a while, they were on an older version.

[andyj]

It's not just the kernel, it's the modules. Just those are 12+ MB compressed, and they'll create lots of data structures when they initialize. I have a bunch of VM's on ESXi and I haven't had much luck with less RAM than 512 MB after adding just some basic extensions. If you want to do something useful like a name server, database, or web server obviously you will need a lot more RAM for those applications.

[the_hopelessest]

Thanks for the fast responses, guys.

Yeah ... I figured ... it might be just outdated info.
However there's something, I believe could be quite important, that I forgot to mention: after TC boots it seems to be using very shy amount of memory (something raging from 37 to 57 MB / 32-64 bit version).
Also: the binary I need to run in it is very lightweight - it requires only openssl as extra dep. and needs almost no memory, so with 256 MBs of memory the VM boots, and then it has around 180 MB memory available, as reported by `free`.

So I figured there's something that happens on boot in RAM that prevents it from booting, and then the 128 MBs would be more than enough ... I thought it's loading too much in memory on boot, related to mounting/decompression/udev/something else (really not knowledgeable enough to know what happens then). Hence my post here, in search of the right configuration/troubleshooting tips to figure that out.

Thanks again.

[curaga]

Udev does spawn several children, which then call modprobe. It's one of many tunables, you can adjust it via your bootloader, though I forget the exact syntax. Something like udev.children-max, a search should find it.

[the_hopelessest]

Something like udev.children-max, a search should find it.

Right! You, sir, saved the day
I read somewhere udev might be taking much memory on boot, but couldn't find how to reduce it. After your hint, I came across an article, which pointed that same parameter.
Anyways - I tried with udev.children-max=0 (which I thought would not spawn any subprocesses and thus would make best use of memory). But in fact, it didn't help at all (not sure why).
Then I (desperately) tried udev.children-max=2 and I was able to boot with 128 MB, and even with 96 MB!

That was exactly what I was looking for! Thanks a lot.

[Rich]

Hi the_hopelessest

... I tried with udev.children-max=0 (which I thought would not spawn any subprocesses and thus would make best use of memory). But in fact, it didn't help at all (not sure why). ...

Setting a parameter to zero does not always mean zero. It could mean  no limit  or something else.