Date: Mon, 22 Jan 2001 10:52:27 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Robert Lipe <robertlipe@usa.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: contigmalloc, M_WAITOK, & leaks. Message-ID: <20010122105227.E7240@fw.wintelcom.net> In-Reply-To: <20010122124539.F10504@rjlhome.sco.com>; from robertlipe@usa.net on Mon, Jan 22, 2001 at 12:45:39PM -0600 References: <20010122110642.B10504@rjlhome.sco.com> <20010122100524.D7240@fw.wintelcom.net> <20010122124539.F10504@rjlhome.sco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Robert Lipe <robertlipe@usa.net> [010122 10:39] wrote: > Alfred Perlstein wrote: > > * Robert Lipe <robertlipe@usa.net> [010122 09:04] wrote: > > > 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? Yes, but it seems like there isn't any. :) > > 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. Yup, it's sort of the fault of the memory allocator, afaik except for allocations that are > (PAGE_SIZE/2), you can't free back to the kernel map, meaning that if you allocate several thousand < (PAGE_SIZE/2) chunks you've pretty much broken contigmalloc. > > 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. Not hinting much, the only reason I can guess that you need contigmalloc is because you're allocating > PAGE_SIZE chunks and you don't want to tell your hardware to do scatter/gather IO and would rather point it at some physically contig memory and be done with it. This is possible (using contigmalloc) if you cache the contigmalloc'd chunks, but not if you keep discarding them and allow the kernel memory map to become more fragmented. > > 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 to do it now. My question is, why exactly do you need contigmalloc, is this some device you're trying to write a driver for? Can you explain it some? That would help me suggest a workaround. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010122105227.E7240>