"A month of sundays ago Horst von Brand wrote:"
> "Peter T. Breuer" <ptb@it.uc3m.es> said:
> > "A month of sundays ago James Sutherland wrote:"
> > > On the contrary - reserving an extra 8Mb of swap per process would
>
> > I replied to your privately already. I don't know how you get this
> > idea. It's easy to show that no process can go OOM on stack if every
> > process has backing reserved to take its stack pages when they have
> > to be taken out of ram for whatever reason.
> >
> > > CAUSE further OOM problems. You would still run OOM, it would just
>
> OK, again, slowly this time:
>
> You allocate 8Mb for stack for each process on your system (here, a very
> underworked workstation, 88 processes right now). That means some 800Mb of
> space that is reserved. Add the potential size of the processes data areas
Correct so far (but no, incorrect, there is nothing to add).
> themselves, say some other 800Mb, and this machine can't handle the load: I
Oh, yes it can. I'm sorry, but the "data area" is a red herring, if by
that you mean memory obtained by malloc. That's purely up to you the
programmer to get and deal with. (I'm aware that gcc sometimes implants
calls, but that's again up to you to to deal with at the compiling
stage). Do it. Be prepared for a zero return from malloc.
> has 128Mb RAM + 128Mb swap. With your scheme it won't even be able to
Well, you'd better not attempt to run it as a secure system then! Horst
- calm down, and THINK about it. If you are running every job on your
system as a secure job that requires 8MB of backing store before it
will start up, then you had better cough up for a disk with
the 2GB of swap required or I, at least, will laugh and refer you to
TFM.
Otherwise your system will not start. So Don't Do That Then. Start the
jobs on your system that need guarantees against being killed as secure
jobs, with 8MB of backing store guaranteed for each of them. Let the
rest run as you like. If you run out of backing store, using the
simple accounting rule of 8MB per secure process, then you can't start
any more _secure_ processes. Simple as that. That's all. Nothing stops
you running ls, or df. And nothing stops you waiting until you have 8MB
of backing store available again so that you can start another secure
job.
> finish booting before going OOM. Forget about minor jobs such as compiling
No, it will not go out of memory.
> a kernel or (horror of horrors) egcs + running its testsuite. Which I do
These are not secure jobs, and even so, why should I forget about it
even if I were so daft as to run them as secure jobs? I could give you
2GB of swap of my system right now and not even notice.
> regularly.
>
> Sure, no process can go OOM. The system goes down in flames way before.
No it does not. See above.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:26 EST