Messages in this thread |  | | | Date | Sat, 29 Nov 1997 11:05:39 +0100 | | From | Jan Echternach <> | | Subject | Re: fork: out of memory |
| |
On 28 November 1997, Zlatko Calusic <Zlatko.Calusic@CARNet.hr> wrote: > Jan Echternach <jec@DInet.de> writes: > > Compiling a driver statically into the kernel is not always an option. > > Maybe you're short on memory, or you want to fiddle with some compile- > > time options or debug the driver without rebooting once in a minute. > > > > So, you're short of 20,30 KB for driver, and thus decide to allocate > (mostly) unused 128 or even 256 KB (to be sure DMA requests always > succeed), so that you can load your driver?
Agreed. The better solution is to keep not just a certain number of free pages around, but to additionally require that these pages are DMA-able and unfragmented. But wait, this is wrong. You don't need to have these pages ready for you in advance (unless you're allocating a 64 KB DMA puffer in an interrupt handler). It should be sufficient to free up the required memory (DMA-able or not, depending on what was requested) in __get_free_pages. This can be done by either swapping out some pages or by moving pages to a different physical location (i.e. the equivalent of a swap out + immediate swap in). The latter is even allowed inside an interrupt handler (GFP_ATOMIC).
There should be no actual performance penalties. When the current __get_free_pages would fail the improved version probably doesn't fail but is only a bit slower than a normal __get_free_pages call. There won't be any user-visible changes except this.
What do the kernel gurus think about this proposal? Have I overlooked something?
-- Jan Echternach
Delta Internet http://www.DInet.de/ Tel. +49 2932 91 6 161 Zeit UmZuDenken! Fax. +49 2932 91 6 230
|  |