Horst von Brand wrote:
> A personal workstation is quite different than
> a fileserver, a webserver, a router or a firewall.
--- That may be the heart of this discussion ... it is possible we have different ideas of how the kernel/OS should act based on perceived roles we see it playing. In no way am I stating that one *always* wants to prevent OOM, or kernel-based process killing policy. I'm simply saying it should be a configurable behavior. As such, I feel it would allow Linux to be useful in more roles.For example. In a C2 security system, if something happens such that auditing cannot continue, it is preferable that the system be shut down (or suspended, or deadlocked). Such behavior is very unlikely what *I* want on my personal workstation or what most people want, but *some* people want that behavior. I would like to see the framework to allow a range of behaviors to allow Linux to play a range of 'roles'.
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. 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?
-l
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- 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