On Thu, 15 Apr 1999, Mikhail Teterin wrote: > > I think they finally got rid of vswap in later IRIX's after they > > fixed the core swapping code to 'overcommit'. The reality behind > > the virtual swap concept w/ IRIX is based on issues with the original > [...] > > Mmm, that's how they use(d) it then... But can we have a way for an > admin to control the amount of overcommited memory? Ranging from 0 -- no > overcommitment to the entire addressable space less the phisical storage > (the current situation)... And this is different from the per-user class > limit. > > I guess, I'd settle for being able to specify the per-user class: > > . datasize limit in percents of the total available RAM+swap > . kill-order, so the kernel will start killing with the least > important users (and services running in their own sandboxes) > > Does not fix the non-compliance with ANSI, strictly speaking...
This is the part that gets me. You keep claiming ANSI C non-compliance, and we are compliant. If you want to claim non-compliance, then get out the spec and quote chapter and verse. There is nothing in the spec that says how the underlying OS has to treat processes on a global scale. This hasn't a darn thing to do with ANSI C compliance. If you want to argue that you don't like memory overcommit, that's valid, but claiming the non-compliance is throwing FUD. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
