Date: Wed, 14 Apr 1999 19:40:07 -0400 (EDT) From: Mikhail Teterin <mi@misha.cisco.com> To: current@freebsd.org Subject: Re: swap-related problems Message-ID: <199904142340.TAA96857@misha.cisco.com> In-Reply-To: <199904142303.QAA43660@troutmask.apl.washington.edu> from Steve Kargl at "Apr 14, 1999 04:03:27 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Steve Kargl once wrote: > Then, submit your patches to fix the problem preferably with a knob to > turn your patches on/off. From the discussion, I hope you're prepared > to deal with the following scenario: I'll be prepared... I don't think it should be a compile time option, though. May be kernel-compile-time -- malloc isn't really at fault here, it seems... But rather a run-time. > User: I compiled malloc with -DSTRICT_ANSI. Now my system appears > sluggish and I can't run as many processes because of > memory/swap starvation. [...] > Submit your patches to the documentation pointing out the alleged > shortcomings malloc() and friends. "Alleged" :-) > Meanwhile, visit /usr/ports. > /usr/ports/devel/libxalloc > /usr/ports/devel/libmalloc > /usr/ports/devel/libdlmalloc I do not see how they can guarantee the usability of the returned memory with the current kernel. There apparently is no way of knowing at malloc time if the memory can be used. Worse then that, it may be possible to use it at malloc time, but unless your program runs and touches every page, the memory may not be available later. If we are up to discussing the possible implementations, I'd suggest that the system uses something other then SIGKILL to notify the program it's time to pay for the over-commit speed and convenience. I think, SIGBUS is appropriate, but I'm not sure. Anything a program can _catch_ and react upon, if its author chooses to. Then, one can write a safe malloc, which will install the signal handler, and touch every page in the the memory referenced by the to-be-returned pointer. If the signal handler is invoked in the progress, the to-be-returned memory must be returned back to the system and NULL should be returned to the caller. Whether or not to use this "safe" malloc can be determined by malloc options and/or the size of the request. However, my (in)ability to propose anything remotely sensible does not change the facts established in this painful thread. That our malloc does not conform to standards (for whatever reasons), and that something should be done about it. That "something" must start with documenting the flaw... -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904142340.TAA96857>