> > For your system, since you aren't running mission critical stuff, you
> >can choose to allocate 1G of Vmem, and implement 'killing' on the above
> >formula. But the *simple* behavior should be the most predictable -- that
> >of "no mem" resulting in ENOMEM on calls asking for memory.
>
> Why bother, when there is a definate disadvantage go doing so, and your
> process can run OOM without getting ENOMEM anyway?
--- The idea is *predictability*. Guarantees of behavior. Your user deamon is fine for many cases, but it's execution is not deterministic. What's in the config files may or may not represent what is in memory (assuming it can be sent a HUP to reread). It may be paged out to disk or even in memory -- may get insufficient priority if real-time processes have priority.If I'm running as an end user -- you would expect me to go read the memory priority policy of the 'hour' to know how my programs will behave? That's not acceptable -- and it is even questionable whether or not on a secure system you'd want to make that information readable by all. On a timeshare system at UCSB, it can make sense to have some sludge'n'fudge on how this topic is handled. On a secure/mission critical system you need the ability to have high integrity, easily predictable systems. Complexity while perhaps proportional to usefulness is inversely proportional to integrity.
You do the user-space demon -- it's a great idea. But let's also agree to implement the vswap idea to allow overcommit or not. That way you can have the behavior you want, and I can have the behavior I *need* and we can both have a 'win-win' situation....? No? Just like for the 2.3 series you have to add a 'shm' entry to continue to use shared memory, in 2.5 somewhere, you can just add a 'vswap' entry to continue to do overcommit.
-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