From owner-freebsd-hackers Mon Jan 22 10:40:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rjlhome.sco.com (unknown [207.65.180.181]) by hub.freebsd.org (Postfix) with ESMTP id 68C7837B401 for ; Mon, 22 Jan 2001 10:39:58 -0800 (PST) Received: by rjlhome.sco.com (8.9.3/SCO5) id MAA11587; Mon, 22 Jan 2001 12:45:39 -0600 (CST) Date: Mon, 22 Jan 2001 12:45:39 -0600 From: Robert Lipe To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: contigmalloc, M_WAITOK, & leaks. Message-ID: <20010122124539.F10504@rjlhome.sco.com> References: <20010122110642.B10504@rjlhome.sco.com> <20010122100524.D7240@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20010122100524.D7240@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Jan 22, 2001 at 10:05:24AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > * Robert Lipe [010122 09:04] wrote: > > I'm calling contigmalloc() with M_WAITOK. For every contigmalloc, I > > have a corresponding contigfree(). But after a few thousand cycles, > > contigmalloc() starts returning NULL. It self-destructs in about 3 > > Making heavy use of contigmalloc is a bad idea, if you really need > this contig allocations then allocate a fair number of them early > and keep using them. I understand that and in a production system, these would indeed be cached. > Memory get's fragmented, there's not much you can do about it. I > doubt that contigmalloc respects the WAITOK flag, there's a good > chance that kernel memory has become so fragmented that your chances > of successfully completing the contigmalloc are near zero, If I were allocating something truly hard to get (like multiple contiguous pages with page alignment) I'd take that answer and move on. I've even given that answer before. :-) But this example requested *no* specified alignment and at any physaddr. So if there's memory in the system (and there must be or malloc couldn't find it) it should be able to find it, right? > it's much better to return a temporary resource failure than block a > kernel thread forever. In this case, the resource failure isn't temporary. Once it starts failing, it fails until the system is rebooted. Since this is on a dedicated thread, I could handle it if it really was temporary. Of course, putting me to sleep so that someone else (or even another of my own threads) could run around and free the resources would be ideal. As it stands, once I get the failure notice, I'm hosed. > This issue has come up before, and most everyone was able to either > use a workaround (calling VTOPHYS? on each page) Tell me more about this. You can't just replace contigmalloc with a malloc and a vtophys becuase you can't express hardware constraints that way. You can express a common subset of them. So there must be something else you're hinting at. > or pre-allocating the contig space and reuseing it instead of > allocating and freeing it over and over. Yes, I'll have a scheme like that that I'll need to implement for performance but I was hoping to defer that. > best of luck, Thanx much, RJL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message