Horst von Brand wrote:
> has 128Mb RAM + 128Mb swap. With your scheme it won't even be able to
I'll just comment that this is a fine mix, horst. I have 128+256 on
my main system - but I normally never go more than 30M into swap, and
that's for "resting" processes.
Given that your system would be slow as molasses if it really was using
100MB of swap for processes that it rotated through page-in frequently,
I suggest you allocate say 64MB for secure processes. That way you can
start 8 secure processes on your system, and the rest has 64MB of
normally accounted swap, plus the 128MB ram.
I'd start init and cron as secure jobs. I can't think of anything else
that needs to be secure. Practically speaking, init in itself is enough
(I run cron from init, and cron checks and revives other daemons).
Note that the "backing swap" for secure processes is only required
as a guarantee that they have a home to go to in case the system runs
low on memory. Knowing that they have a place to go to, the system
can afford to _guarantee_ not to kill them when it wants more memory.
It should/would kill non-secured processes if it can't supply an
overcommit that it's been called on. The secured processes are known to
be not guilty. They don't even have to be sent to swap. What has
happened is that the kernel needs to page in 4k and it can't find
any page to throw out of ram to make way for it. The secure processes
can be thrown out of ram, ergo they're not candidates for sacrifice.
But they don't have to be thrown out of ram to prove it. It's known.
I.e. you'd only get thrashing if every process on your system was
running as a secure process, and ram+swap were full. Just like now.
Indeed, the only change I propose is an accounting change and the only
effect it has is in saying when certain processes can _start up_ (or if
they can). So it has no effect on the characteristics of the system
with respect to those processes already running. Your system would
behave just as it does now. It would just be more secure :-).
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