Re: DMA page allocation

Tom Leete (tleete@access.mountain.net)
Thu, 17 Jun 1999 21:35:14 -0400


-----Original Message-----
From: Jaroslav Kysela <perex@suse.cz>
Date: Wednesday, June 16, 1999 9:32 AM
Subject: DMA page allocation

>Hello,
>
> I'm really tired with the chronic problem of the linux kernel:
>DMA page allocation when the system memory size is far beyond 16MB.
>ALSA users (and OSS/Lite too) complain many times that the DMA buffer
>for a sound chip can't be allocated or it is too small, because the low
>16MB memory is used with another things.
> I tried a little bit to dig to this problem and I found useable
>(I hope) solution: to create two memory pools for pages - one standard and
>second for DMA pages (limited size).
> I prepared a "test" patch (against 2.2.10) which works very well
>for me. In this patch is 2MB of the system memory used for the DMA page
>pool. This limit value could be overriden in the final version of the code
>with an user. The code also needs improvements in some places (to handle
>systems up to 16MB memory, other architectures, allocate only a continuous
>DMA page region etc..).
> I want to discuss this problem and solution with all kernel gurus.
>I really hope, if my solution would be rejected that someone will come
>with another.
>
> Jaroslav

Hi,

If you'd like to try an approach which has proven successful, and which does
not interact so much with core kernel functions:
http://web.mountain.net/~tleete/bigphysarea-config-2.2.9-patch.gz
http://web.mountain.net/~tleete/bigphysarea-config-2.3.3.gz

This is the Matt Welsh bigphysarea patch, with refinements and extras by
Roger Butenuth. I've done a little tweaking and added the feathers to make
it a configuration option.

The DMA area you get from this can be adjusted for size as a boot option. It
begins in the bottom 16M of memory unless your kernel is larger than that
;-)

The bigphysarea has its own simple memory management, so it complies with
your design of two independent memory areas. It is never even seen by vm,
though, so it's unnecessary to persuade vm to ignore it or work around it.

Regards,
Tom

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/