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