On 4/25/22 1:23 PM, Peter J. Philipp wrote:
Hi,

I have an openbsd amsterdam vps and KARL is using up so much RAM that it
causes the system to swap.  I recently upgraded it to 7.1 and it's the first
time I had a problem with this (that I noticed).  I have tried to put KARL
into a login.conf'ed (32 MB data limit) user but ld doesn't like that at all
and exits with a memory allocation failure.

What can I do to make KARL reorder_kernel use less memory without buying more
RAM?  I've turned KARL off for now but that's not a real solution and I hate
it.

Is there no option in the clang 13.0.0 linker to store what it would normally
store in memory to disk?  I know it would be slow but KARL doesn't need to
be fast if it's backgrounded.

yep. It is called "swap".  You just reinvented swap. :)
And KARL is backgrounded already.

I've done some homework googling and found this:
https://stackoverflow.com/questions/25197570/llvm-clang-compile-error-with-memory-exhausted

in the checked solution, 1 and 2 are sorta out of the question, but question is
whether we're using a Debug build of clang?  Does anyone know off hand?

While I'm here thinking about possible solutions it would be cool if I could
allocate a 128 MB vmm inside this vmm (cascaded vmm's?) with a stripped down
KARL building kernel and lots of swap, then it can swap all it wants to while
linking and it leaves the system in reasonable memory without swapping in
the main vm.  Perhaps I'm thinking in over-engineering terms here?

"I have a problem with memory consumption.  I know!  I'll solve it adding a VM!"
Now you have many problems.  I really don't think this is a good idea.

How tiny is this VM???  My smallest intel box currently sitting around and
ready to go is a 400MHz celeron with 512MB RAM, i386 platform, so I just
fired it back up and did a few sysupgrades to bring it up to 7.1-current (ok,
"just" isn't applicable here, I started this test yesterday). I did a reboot
and as soon as I could log back in, did so and watched top -- ld topped out
at about 270MB. That is admittedly huge for an OS I used to do builds on
with 128MB and run in production with 32MB but a couple releases ago, I
found that 384MB was the minimum needed to avoid swap on boot. Doesn't look
much worse now (granted, i386 platform.  I don't know what you are running).

If you are trying to run <512MB RAM, I would politely suggest reconsidering
some life choices here. :)

Alternatively, you might want to think about other options.
KARL is great, but even without it, I think you will find OpenBSD is still far
more robust and secure than the systems your bank runs on, so disabling KARL
is not fatal in my mind for otherwise fairly secure systems.  If you wish to
get overly complicated, you could disable KARL on the production machine and
relink a kernel periodically on ANOTHER machine and put it on the prod
machine after it is built (there's your VM.  Just don't put it on an already
resource-starved system!)

Another idea might be to slip "disknice" into /etc/rc where it rebuilds the
kernel.  It is a cute little bit of code TedU@ wrote a number of years ago,
you can find it here:
https://marc.info/?l=openbsd-misc&m=126526614419455&w=2
It won't stop swapping, but *may* help other tasks get some time.  I've found
it useful on disk I/O tied tasks, but never tried it with a swap-bound task.
I have no idea how it would impact a swapping process.  Might solve your
problem, might do nothing ("doing nothing" counts as hurting when you make
changes to system scripts).

Nick.

Reply via email to