> Maybe if I call the sysctl "vm.crashmenow". No, that will just make more > people actually try it. It might be doable as a compile-time option, > since you wouldn't be able to run anything approaching standard on > such a system anyway. I don't see much use for it myself. As I said > before, there are easier ways to manage memory that are not quite as > arbitrary as simply refusing a potential overcommit. Perhaps it could be an additional flag to mmap, in this way people wishing to run an overcommited system could do so but those writing programs which must not overcommit for certain memory allocations could ensure they did not do so. Regards, Niall To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
- Re: Replacement for grep(1) (part 2) Daniel C. Sobral
- Re: Replacement for grep(1) (part 2) David Brownlee
- Re: Replacement for grep(1) (part 2) Jason Thorpe
- Re: Replacement for grep(1) (part 2) Matthew Dillon
- Re: Replacement for grep(1) (part 2) David Greenman
- Re: Replacement for grep(1) (part 2) Jason Thorpe
- Re: Replacement for grep(1) (part 2) Mike Smith
- Re: Replacement for grep(1) (part 2) Daniel C. Sobral
- Re: Replacement for grep(1) (part 2) Jason Thorpe
- Re: Replacement for grep(1) (part 2) Matthew Dillon
- Re: Replacement for grep(1) (part 2) Niall Smart
- Re: Replacement for grep(1) (part 2) Michael Richardson
- Re: Replacement for grep(1) (part 2) Brian F. Feldman
- Re: Replacement for grep(1) (part 2) Jason Thorpe
- Re: Replacement for grep(1) (part 2) Mike Smith
- Re: Replacement for grep(1) (part 2) Daniel C. Sobral
- Re: Replacement for grep(1) (part 2) Kevin Schoedel
- Re: Replacement for grep(1) (part 2) Daniel C. Sobral
- Re: Replacement for grep(1) (part 2) Valentin Nechayev
- Re: Replacement for grep(1) (part 2) John Nemeth
- Re: Replacement for grep(1) (part 2) Daniel C. Sobral