Linda Walsh <law@sgi.com> said:
> Horst von Brand wrote:
[...]
> In the examples you gave of kernel memory usage:
> | > What other system calls/functions overcommit?
> | The kernel does vmalloc() and kmalloc() and such internally, page tables
> | use space, then there are buffers and caches of several classes. Just
> | receiving network traffic uses up RAM, handling routes, IP addresses and
> | ARP ditto, ... If you use many file descriptors, this uses RAM too...
> Does the kernel actually allocate all of these and just "not use
> them" -- i.e. are these really cases of where space is allocated and then
> goes unused? I'd think all of these are cases where the kernel was
> expecting to actually use the memory and really doesn't want a
> non-physical allocation, but a real, physical allocation.
AFAIKS, the kernel is careful to ask for memory (real RAM, not swap space!)
only if it really needs it. But it also uses "otherwise unused" memory for
various caches, which can be cut back if the need arises.
> Specifically I
> was thinking of calls that used overcommit -- meaning allocing space that
> they really didn't intend to use, but you are right -- all of those cases
> would need to be handled as far as memory allocation bookkeeping. But we
> already do bookkeeping for 'free' memory, 'used' memory, 'shared' memory
> -- would adding 'committed' or 'reserved' memory really be that much more
> difficult or costly?
Not in itself, the problem is that if you don't ever want to overcommit
anything you must know exactly how much memory each activity could use, in
the very worst case. And to set things up that way is _hard_. No recursion,
bounded ammount of memory you can {v,k}malloc(), bunded space for buffers,
bounded space for handling incomming TCP connections, bounded space for ARP
cache, ... probably not very hard to do for each one of them individually,
but there are lots of activities to consider. Besides, if you set one of
them up with too little memory, it might deadlock the system. And then, if
you want them to share the total alloted to the kernel, who is it safe to
steal memory from when it runs out? It is a very nasty can of worms as I
see it.
I can understand there are people worried by stuff like C2 security, but in
that case you can work with overcommitment, just make sure the tasks
crucial for C2 can't run out of resources (unless they are broken or the
sysadmin is a complete idiot, that is), and then do as you say: If they do
run out, take the whole system down.
As things stand today, if you want a truly compartamentalized system you'd
probably be better off running each compartment on a completely separate
machine. At least security-wise, and most probably even cost-wise (to
develop and audit an air gap between two systems is a bit cheaper than
ensuring equivalent isolation among tasks on the same machine ;-)
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- 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:20 EST