Re: clang 13 space issues with KARL
On Thu, Apr 28, 2022 at 07:57:20PM +0200, Peter J. Philipp wrote: > On Thu, Apr 28, 2022 at 11:47:14AM -0600, Theo de Raadt wrote: > > >On Thu, Apr 28, 2022 at 10:44:09AM -0600, Theo de Raadt wrote: > > >> If people built properly sized machines there would be no problem. > > > > > >That's a little condescending don't you think? > > > > Not at all. > > > > If you don't use a tool as it was intended, you bear the consequences. > > > > *WE* built the tool. *WE* decided how it works. We even documented > > how much resources it typically needs. When people use it > > incorrectly, it is their own damn fault. *THEY* can make adjustments. > > > > But they cannot complain, because they did not pay and even if they > > had there is no warrantee. > > > > There is nothing condescending about telling someone their complaints > > about how something works are falling on deaf ears. I don't give a > > flying damn if KARL is hurting people who don't provide their machines > > with reasonable defaults. It is their own damn fault, and they can > > make manual accomodations for their own (completely stupid, IMHO) > > decisions. > > > > In this modern world is has become *impossible* to complain about > > any technology which doesn't work like you want, companies who take > > money don't give a damn. Here's the shocker: I will not be held > > to a higher standard than that. So Peter, your attitude stinks > > and your suggestion that anything I've said is "rude" rather than "real", > > thgat suggestion of yours is an insult. > > OK, I get it you're having a bad day. I'm sorry if I was rude. > > BTW do you know any operating systems that aren't BSD, Linux that I can > continue on? Surely you'd be in the know for this. > > -peter > This is the second time in a week someone has posted on tech or misc asking why we don't run well on ancient or ridiculously low resource machines. Your question about why KARL doesn't work well on such machines is effectively the same as "why doesn't LLVM work well on my ridiculously small machine?" I'd suggest that question should go to the llvm developer mailing list. We don't control how much RAM LLVM requires. I can totally see where theo is coming from. -ml
Re: clang 13 space issues with KARL
On Thu, Apr 28, 2022 at 2:00 PM Peter J. Philipp wrote: > BTW do you know any operating systems that aren't BSD, Linux that I can > continue on? Surely you'd be in the know for this. If you do not mind using msdos as a bootstrap loader, you might try colorforth. For example: https://colorforth.github.io/install.htm That said, if you are looking for a community to support that effort, you might have to build it yourself. This isn't really the right place for that. Good luck, -- Raul
Re: clang 13 space issues with KARL
On Thu, Apr 28, 2022 at 11:47:14AM -0600, Theo de Raadt wrote: > >On Thu, Apr 28, 2022 at 10:44:09AM -0600, Theo de Raadt wrote: > >> If people built properly sized machines there would be no problem. > > > >That's a little condescending don't you think? > > Not at all. > > If you don't use a tool as it was intended, you bear the consequences. > > *WE* built the tool. *WE* decided how it works. We even documented > how much resources it typically needs. When people use it > incorrectly, it is their own damn fault. *THEY* can make adjustments. > > But they cannot complain, because they did not pay and even if they > had there is no warrantee. > > There is nothing condescending about telling someone their complaints > about how something works are falling on deaf ears. I don't give a > flying damn if KARL is hurting people who don't provide their machines > with reasonable defaults. It is their own damn fault, and they can > make manual accomodations for their own (completely stupid, IMHO) > decisions. > > In this modern world is has become *impossible* to complain about > any technology which doesn't work like you want, companies who take > money don't give a damn. Here's the shocker: I will not be held > to a higher standard than that. So Peter, your attitude stinks > and your suggestion that anything I've said is "rude" rather than "real", > thgat suggestion of yours is an insult. OK, I get it you're having a bad day. I'm sorry if I was rude. BTW do you know any operating systems that aren't BSD, Linux that I can continue on? Surely you'd be in the know for this. -peter
Re: clang 13 space issues with KARL
>On Thu, Apr 28, 2022 at 10:44:09AM -0600, Theo de Raadt wrote: >> If people built properly sized machines there would be no problem. > >That's a little condescending don't you think? Not at all. If you don't use a tool as it was intended, you bear the consequences. *WE* built the tool. *WE* decided how it works. We even documented how much resources it typically needs. When people use it incorrectly, it is their own damn fault. *THEY* can make adjustments. But they cannot complain, because they did not pay and even if they had there is no warrantee. There is nothing condescending about telling someone their complaints about how something works are falling on deaf ears. I don't give a flying damn if KARL is hurting people who don't provide their machines with reasonable defaults. It is their own damn fault, and they can make manual accomodations for their own (completely stupid, IMHO) decisions. In this modern world is has become *impossible* to complain about any technology which doesn't work like you want, companies who take money don't give a damn. Here's the shocker: I will not be held to a higher standard than that. So Peter, your attitude stinks and your suggestion that anything I've said is "rude" rather than "real", thgat suggestion of yours is an insult.
Re: clang 13 space issues with KARL
On Thu, Apr 28, 2022 at 10:44:09AM -0600, Theo de Raadt wrote: > If people built properly sized machines there would be no problem. That's a little condescending don't you think? -peter
Re: clang 13 space issues with KARL
>On 2022-04-27, Nick Holland wrote: >>> 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. > >And that's the problem in some cases: /bin/time -l says that >reorder_kernel uses ~650MB rss on my laptop. Depending on what else you >have running (noting that daemons, which are often starting at around >the same time as reorder_kernel runs, often use more RAM during startup >than in a steady state) that can be enough to tip it over the edge. 650MB rss why is this a big deal? I think people are building tiny little machines that Linux would never run on, and then inventing complaints. If people built properly sized machines there would be no problem. Alternatively, they should grow up and go work on making the linker use less memory. I do not understand why this complaint exists. If you built a machine that cannot link a kernel, your machine is very likely Not Fit For Modern Purposes. Grow up, this is not the year 2000.
Re: clang 13 space issues with KARL
On 2022-04-27, Nick Holland wrote: >> 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. And that's the problem in some cases: /bin/time -l says that reorder_kernel uses ~650MB rss on my laptop. Depending on what else you have running (noting that daemons, which are often starting at around the same time as reorder_kernel runs, often use more RAM during startup than in a steady state) that can be enough to tip it over the edge.
Re: clang 13 space issues with KARL
On Wed, Apr 27, 2022 at 11:32:06AM -0400, Nick Holland wrote:
> 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.
Oh goody! When I look at this VPS it has 1 GB of RAM, 1/2 of all resources
are used up by daemons (around 512 MB) and the rest is in buffer cache and
free memory. I don't care much about 45 MB being swapped out to disk really
but if I'm correct this does have a negative impact on openbsd.amsterdam and
was the reason they gave us a free RAM upgrade before.
> > 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
1 GB RAM.
> 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
You can't compare i386 to amd64 the memory footprint is a lot smaller in i386.
But I see where you're going with this: <=512 MB RAM is too low for a machine.
> 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. :)
Not the case here. Although I'm constantly searching for new opportunities
which affect my life choices regardless.
> 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!)
This is a good idea and I haven't thought of it. I may do this.
> 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=126526614419455=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).
I like your first recommendation better somehow, thanks very much though.
> Nick.
>
Best Regards,
-peter
Re: clang 13 space issues with KARL
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=126526614419455=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.
clang 13 space issues with KARL
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. 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? Best Regards, -peter
