Re: fork: out of memory

Jan Echternach (jec@DInet.de)
Wed, 26 Nov 1997 15:53:19 +0100


On 26 November 1997, Mike Jagdis <mike@roan.co.uk> wrote:
> Paging *is* on in the kernel. It isn't so much a case of the kernel
> seeing contiguous memory as of devices seeing *physically*
> contiguous memory. There are a few case where we know nothing
> will want to do DMA to a multi-page region and in such cases we
> could use vmalloc (which already exists) but that has a relatively
> heavy set up / tear down penalty so better solutions that don't
> use vmalloc are prefered. Vmalloc doesn't help the problem that
> much anyway - most of the big page requests are for things like
> floppy buffers and sound buffers which have to be physically
> contiguous for DMA.

But if we need a DMA buffer that is physically contiguous can't we
just move non-DMA pages around and adjust the page tables such that
logical addresses stay the same?

> > or (b) when you can't find
> > 8 contiguous pages, pick the first free page and swap
> > the data in the next 7 adjacent pages with other free
> > pages in memory. Method (b) could construct any number of
> > contiguous free pages atomically with the only penalty
> > being some chunky memcpy's ...
>
> Plus you have the overhead of changing references, plus you have
> cache penalty overheads if you move a hot page. But if you manage
> the page pool well you can make good decisions and use reclaim
> if necessary quite effectively. As long as you don't let dirty
> pages build up even large atomic requests should be satisfiable.

It should be possible to change page tables and let all other references
stay the same. And if performance is lower it is still better than
"fd0: can't alloc DMA buffers" (note that moving pages is only
necessary if the allocation would fail otherwise).

-- 
Jan