Date: Sat, 16 Nov 2002 13:52:04 -0500 (EST) From: Gary Thorpe <gathorpe79@yahoo.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-hackers@freebsd.org Subject: Re: bus_dmamem_alloc failing Message-ID: <20021116185204.61345.qmail@web41211.mail.yahoo.com> In-Reply-To: <3DD58757.1936774C@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Terry Lambert <tlambert2@mindspring.com> wrote: > 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. Does UNIX have the ability to specify "wired" pages that will not be paged out and will always remain in memory? > > It's still possible to do wbithout kernel paging, but it will > be a lot harder. Since most DMA controllers do not know about virtual memory but only physical memory, wouldn't it be unworkable to put memory used in dma transfers into virtual (paged) memory? A x86 DMA transfer also requires that this memory is physically contiguous right? I *think* other architectures can do dma to virtual memory (MIPS, SPARC???). Even if kernel paging is not necessarily the solution in this case, would it make some things easier? However, wouldn't it also make the system much less reliable since FreeBSD overallocates memory? What do you do when the kernel triggers a page fault and there is nowhere to put the incoming page (and no swap space to page out the page it will replace)? Reliable in this case means random processes will not be killed. > > > 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. This would not free the resources used by the driver and would effectively mean that a driver can be enabled and disabled but never really unloaded. > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca 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?20021116185204.61345.qmail>