In message <[EMAIL PROTECTED]>, >And maybe, just maybe, they'll succeed in getting their >idea of non-overcommit working with a patch which doesn't >change dozens of places in the kernel and doesn't add >any measurable overhead. If it adds overhead, fine, make it a kernel option. :) Anyway, no, I'm not going to contribute code right now. If I get time to do this at all, I'll probably do it to UVM first. My main objection was to the claim that the C standard allows random segfaults. It doesn't. And yes, bad hardware is a conformance violation. :) -s To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
- Re: Setting memory allocator... Wes Peters
- Re: Setting memory allocator... Julian Elischer
- Re: Setting memory allocator... Arun Sharma
- Re: Setting memory allocator... Nate Williams
- Re: Setting memory allocator... Peter Seebach
- Re: Setting memory allocator... Nate Williams
- Re: Setting memory allocator... Peter Seebach
- Re: Setting memory allocator... Matt Dillon
- Re: Setting memory allocator... Peter Seebach
- Re: Setting memory allocator... Rik van Riel
- Re: Setting memory allocator... Peter Seebach
- Re: Setting memory allocator... Rik van Riel
- Re: Setting memory allocator... Peter Seebach
- Re: Setting memory allocator... Peter Seebach
- Re: Setting memory allocators for library... Julian Elischer
- Re: Setting memory allocators for lib... Daniel C. Sobral
- Re: Setting memory allocators fo... Dag-Erling Smorgrav
- Re: Setting memory allocators for library fun... Tony Finch
- Re: Setting memory allocators for library... Dag-Erling Smorgrav
- Re: Setting memory allocators for library functions. Thomas David Rivers
- Re: Setting memory allocators for library functions. michael schuster