On Sat, 25 Mar 2000, Linda Walsh wrote:
>> > 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.
You're ignoring the stack.
And with Rik's OOM killer patch, particularly with the modifications and
daemon I'm proposing, things *are* very predictable. And as an added
bonus, you get overcommit. This system is much more efficient.
>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 is deterministic. (And yes, it catches SIGHUP.)
If the configuration file doesn't specify a priority for some task, then
it gets a default value. Furthermore, priorities can be specified on a
per-user AND per-task basis.
>It may be paged out to disk or even in memory
No, that can not happen. I call mlockall().
>may get insufficient priority if real-time processes have priority.
It already sets it's nice value to -20, and I will probably set it to
SCHED_RR.
The downside to my daemon is that I suspect it's not too CPU friendly
for systems with lots of processes...
> 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.
Policies change only when the sysadmin changes the config file and sends
the daemon a SIGHUP. If this happens and your task hits the soft limit
when the system is low on memory and receives SIGSTOP, go complain to the
sysadmin.
This is the only sensible way to do things. All computer systems have
limited memory. If that limit is hit, something has to give.
My daemon sets up quotas, with hard and soft limits. But it still lets
each user go over the limits, so long as the system has lots of memory
left. When memory gets low, the daemon finds users that have exceeded
their limits and sends the appropriate signals. However it is trivial to
change the behavior to not allow overcommit, and I may make this a command
line option to appease the masses.
> 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?
No, because disabling overcommit doesn't solve your problem.
The solution to the problem is the following:
1. Run Rik van Riel's OOM killer patch
2. Use a machine that has enough memory to handle the load
3. If the machine runs out of memory, invoke #1
4. (optional) use quotas and/or my daemon to make #3 predictable
Dave
David Whysong dwhysong@physics.ucsb.edu
Astrophysics graduate student University of California, Santa Barbara
My public PGP keys are on my web page - http://www.physics.ucsb.edu/~dwhysong
DSS PGP Key 0x903F5BD6 : FE78 91FE 4508 106F 7C88 1706 B792 6995 903F 5BD6
D-H PGP key 0x5DAB0F91 : BC33 0F36 FCCD E72C 441F 663A 72ED 7FB7 5DAB 0F91
-
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