> Having no idea of what programs root would execute doesn't mean
> > you can't reserve sufficient memory for a shell, a ps and a kill. But if
> > my machine runs out of processes and I can't log in -- I have little choice
> > but to hit the RESET button.
>
> And if root logs in to play a game of nethack, what then?
--- Depends on if nethack is larger than the reserved memory. If so, root can't run it and maybe they'll be responsible enough to figure out why? Hey...what happens if root logs in and does an "init 1"...what's your point? If there is a problem they can choose to deal with it or not. I dunno about you, but when I had a run amok process eating processes, when I managed to free up a process so I could login and kill the runaway process, I chose to kill the process -- not play a game. But hey, some people's priorities may be different.> > > > Therefore all known Unix Operating Systems allow the use of > > > 'currently unused' virtual RAM. This RAM may have been allocated, but > > > it has not been touched yet. The tasks that have allocated it will > > > not even know that it was 'borrowed'. This is the nature of > > > "over commit". > > > Not all unix systems, however, allow it by default. Some have > > realized that allocating memory with no "assurance" lowers the overall > > integrity/security of the system. Some require that an administrator > > explicitly allow the unsafe behavior after they have learned about the > > implications. > > OK, how about telling us among Unices (or similar) which ones allow > overcommit or not be set. --- I do not presume to know all like you did. I do know IRIX doesn't allow overcommit by default. I only need 1 case to disprove your assertion. I'd assume some other companies have dealt with this in an intelligent manner as well. Sun, I believe, has a B1 trusted system. I'd be surprised if it's specification allowed or included random processes to be killed on the fly. In fact, that would be a direct violation of B1 security. You can't have the actions of one user denying service to another.
> > By allowing 'overcommit', you end up in a situation where now your > > 90M process touches the last of its memory -- and it isn't there, so.... > > it SEGFAULT's because the memory mapper can't the address to a physical \ > > object? > > By not overcommiting, that 90Mb process either doesn't get off the ground, > or nothing else can run at all. -- Exactly! You know about the problem ASAP rather than after it has run for 3 weeks and possibly is killed and loses 3 weeks of calculations. Dunno about you -- but I'd rather know sooner than 3 weeks from now if my program is going to work.
> Even if the *potentially* 90Mb process > isn't using much memory ATM. And if the 90Mb process asks for memory a bit > at a time, it can get killed for trying to get memory which others have > reserved because they might use it, like 8Mb for stack for ls(1) asked to > see if file foo exists. --- If you have insufficient memory to fork it's the same as insufficient processes -- the fork fails -- very predictably. > > > If you allow overcommit, you can have *either* the SEGFAULT behavior > > *or* the no-mem/locked out (process touches everything up front). If you > > disallow overcommit, you reduce the possible behaviors to 1. The problem is > > that suppose the process allocates it's memory -- with the 'overcommit' > > you have a system where it is hard to predict *what* will fail. Will it be > > a system process? A deamon? It's a low-integrity system because you can't > > figure out the behavior of failure in advance. > > It isn't harder to predict than in the no overcommit case: Some process > gets killed, the one that happens to ask for memory when the system can't > commit more (essentially at random), or (much, much later in the life of > whatever got the system OOM) some probable culprit (Rik's patch). --- No! -- Killing is bad. Returning an error condition is good. Regardless of the use of SIGSTKFLT with floating point, if that signal can't be overloaded then maybe another is more appropriate. If hard memory quotas are implemented, wouldn't they also send some signal when the soft limit was reached?
> > > David's killing demon is fine for a user-space/level solution, but > > the kernel should default to the high-integrity option. > > Nonsense. Few people are prepared to shell out 5 times the needed RAM + > swap just in case everybody decides unanimously to change all pages at > their reach. True, there are applications where this is required, but they > are far in between. --- If you want to use Linux for mission critical applications, cost is not usually an issue. For those for whom cost is an issue, just add a couple of Gig or infinite vswap. This allows for *both* to be happy....but that won't please you > > [...] > > > This way you could allow someone to create the same behavior as > > now, but by explicit choice by the sysadmin. > > Please, yet again: OOM is an extreme situation, if you let your system go > that far with any frequency then _you_ are broken, or the system is > hopelessly underspeced. ---- Perhaps. I used to run w/o any swap @ all because I wanted to know when I hit disk and performance was impacted. Only reason I run w/swap now is I can get optionally get core dumps. So my preference is to have a program fail to load if I don't have the swap. Then I know immediately I need to look for memory hogs, retune my system, or buy more memory or expand my swap on disk. Disk space is *cheap*. About 1cent a megabyte and dropping. That means for $40 I can have a 4 Gig swap space. I have 256M on my machine. If I'm overcommitted at 4G, something is *way* wrong.
> If you add non-overcommit to a overworked machine > you get very predictable behaviour, i.e., none at all. ---- *Exactly*. This is what I would want. It's a flag to me that something is broken. If I have a need and can't add swap, I could always add vswap and continue on in the same manner as now, but I know I'm literally running on 'borrowed memory'. I'm immediately aware that if I want to add a departmental HTTP server to my machine, I really should add more memory or face real performance problems. It's all about choice. Creating verified memory for a process doesn't prohibit running w/o it. You are arguing against a strawman.
> Coding up any of the > wonderful "easy, non overcommiting schemes" is _hard_ and would need > extensive changes in the kernel (the kernel _does_ use memory, and such use > is not bounded today). --- Yeah....is that the real reason we are having this argument? Because it's hard? I agree -- it seems daunting -- possibly something out of my league. That doesn't mean we can't agree on a *desired* facility.
> This would undobtedly cost quite a bit in > performance, together with the performance loss of allocating swap space > for nothing. --- I don't think it would be that expensive -- Rik doesn't think it would be that expensive and he knows the code alot better than I, so I'll agree w/him on the cost. :-)
-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:16 EST