Messages in this thread | | | Date | Mon, 10 Mar 1997 16:16:31 +0000 (GMT) | From | Mark Hemment <> | Subject | Re: Couldn't get a free page |
| |
G'Day,
On Mon, 10 Mar 1997, Richard B. Johnson wrote: > Hello memory manager wizards........ > > What #define do I change and were to get some more pages for Disc I/O? > I can't write a large amount of data to a raw SCSI device for testing. > I use the BusLogic driver. It gets memory for "DMA" from the kernel. > It runs out and hangs.
I'm not familiar with the BusLogic driver, but a quick peek shows it does allocations atomically. Do you know what order of pages it is asking for?
You could make the kswapd (mm/vmscan.c) more aggressive, although that will hit your over all performance. Try a few values for the following;
mm/vmscan.c o make the "swapout_interval" smaller (not really recommended) o kswapd_ctl() push up the '4' (maxpages) upwards (16 or 32, 128?). This is the number of pages the daemon tries to reap. o a bit of coding in the function kswapd(). Make sure it calls try_to_free_page() with the second argument of 1 every other time around the loop. (means get DMA memory). This is should help. mm/page_alloc.c o Hack in free_area_init(). You want to push up the values for "free_pages_low" and "free_pages_high". These are the water-marks for the daemon. Pushing up "min_free_pages", might also be a good idea (it controls when gfp() reaps pages for non-atomic requests).
It's also possible to mess around with the page-aging, so its easier for try_to_free_page(). Look in mm/swap.c for "swap_control". The first four members control page aging (the buffer aging is ignored). The values are; 20 - max page age 3 - increment for when a page is referenced (used to touch_page()) 1 - decrement for when a page is not refenced (used to age_page()) 3 - initial page age.
Make the increment '2', and the max-page age 10. Will probably hit your performance nicely, but will help try_to_swap_out() to release a page.
I'm guessing, but the problem is probably that the pages kept back for atomic requests are not DMAable. Alternatively, the gfp() request is for a non-zero order of free pages (which always difficult to get atomically).
What is the exact error message? You are positive it is the driver where the memory request fails?
Isn't only ISA DMA memory restricted to the low 16MBs? Perhaps some architecture guru could say if the GFP_DMA flag could be removed from the gfp request for your arch.
I've been messing around with the VM sub-system, and started this morning on a new page reaper (using active and inactive lists) which means some page reaping take place for atomic requests.
Regards,
markhe
| |