Date: Fri, 15 Nov 2002 15:46:31 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Chuck Tuffli <chuck_tuffli@agilent.com> Cc: mark tinguely <tinguely@web.cs.ndsu.nodak.edu>, freebsd-hackers@FreeBSD.ORG Subject: Re: bus_dmamem_alloc failing Message-ID: <3DD58757.1936774C@mindspring.com> References: <20021115164813.GB19814@cre85086tuf.rose.agilent.com> <200211151703.gAFH3ij16483@web.cs.ndsu.nodak.edu> <20021115175028.GC19814@cre85086tuf.rose.agilent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Chuck Tuffli wrote: > On Fri, Nov 15, 2002 at 11:03:44AM -0600, mark tinguely wrote: > [snip] > > The memory is avaliable to the kernel/drivers when bus_dmamem_free() is > > called. The problem for you is that someone else does allocate a > > page within the 16 page chunk making it unable to reallocatable by you, > > so the next bus_dmamem_alloc() looks for the next 16 page contiguous > > chunk. This continues until there is no more 16 page contiguous chunks > > available and the bus_dmamem_alloc() fails. FreeBSD does not have a > > physical memory defragmenter. > > Ok, I get it now. Thanks to all for the explanation. Would a physical > defragmenter be of interest? I can't work on it right away, but if > there is interest, I could take a look at this later. I find it interesting, every time this issue comes up. The big problem, as I see it, is that it has to avoid things it already holds references to, so basically all code used in the defragmentation path has to be immune to defragmentation (very much like the Windows disk defragmentation, which can not move swap blocks, because part of the defragmenter itself might be swapped out to one of them). Really, there's a lot of the kernel which could be pageable, which would help this. But for this to work, all the code in the paging path has to be marked non-pageable. The way Windows handles this is to have seperate ELF sections for pageable vs. unpageable vs. init vs. other code/data. At present, FreeBSD only supports the concept of code, data, and BSS sections, so you would need to change the loader, if you wanted to do this. It's still possible to do wbithout kernel paging, but it will be a lot harder. All that said, I think people with clue would sing your praises from the rooftops if you did this; among other things, it would let code like video capture cards, which need huge contiguous areas, be loaded and unloaded and reloaded well after boot time (right now, if you don't load them at boot time, you are likely to be unable to load them at all, for lack of a large contiguous area of physical memory). Meanwhile, a common approach is to have a seperate patial driver to do the memory allocation on your behalf, and hold the references, but do nothing with them, so that you can load and unload the actual driver mechanics while you are developing the driver in the first place. Then you reference the memory allocated by the first driver from your module, instead of allocating and deallocating it each time. -- Terry 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?3DD58757.1936774C>