[lkml]   [1999]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: A DMA patch for linux 2.2.9
In article <>,
Alan Cox <> wrote:
>> > to indicate if the architecture has the DMA memory limit and each
>> > architecture can turn it off at the runt-time. We then can do
>> Some PCI devices (eg Trident 4dwave-NX) have limited address space for DMA
>> registers (eg it can only address 1gb memory). So on really large machines
>> (eg 2gb) it is still possible to run out of DMA memory. 8)
>This is (unfortunately) very common on PCI cards aimed solely at the PC
>market. We have for example..
> ES1370 top 4 bits of irq registered wired to 0
> ESS Maestro 27bit addressing limit. All audio dma buffers within
> 4 256K chunks

Is it unreasonable to simply add a few flags to the memory allocator to
specify the hardware constraints on memory to be allocated? This seems to
be more and more necessary as more and more
not-spec-compliant-but-good-enough-for-Windoze hardware is supported.

What if we give the memory management system the following parameters
at run-time for each DMA participant (buses and cards alike):

alignment - number of least-significant bits that must be zero
(probably won't support less than 12 in practice)
sigbits - number of significant bits (including alignment)

So we have:

alignment sigbits description
1 24 ISA 16-bit DMA
18 27 ESS Maestro (one interpretation *)
0 27 ESS Maestro (another interpretation *)
0 28 ES1370
0 30 Trident 4dwave-NX
0 31 PCI bus on ia32
12 32 ia32 pages
13 64 Alpha pages

* I'm not sure what Alan means by the 256K chunks...256K-aligned chunks,
or just chunks of size 256K with no particular alignment constraint?
Also the alignment is probably '2' in many places where I've said '0'...
Alphas don't really fit into this since they use both the high and low
bits of each word and ignore about 30 bits in betweeen. I'd imagine
some of the old M68K architectures have even weirder stuff.

The module setup (or monolithic initialization code) can inform the memory
allocation subsystem that requests for memory with this kind of alignment
are to be expected, so the allocator can dynamically allocate memory in
a manner that attempts to preserve memory with these characteristics.
DMA memory requests should specify the alignment and sigbits values,
and the memory management system will try to find pages that satisfy
as few of the known constraints as possible. This includes swapping out
swappable pages if necessary to allocate non-swappable memory given a
particular constraint, and only allocating non-swappable memory outside
of its minimal constraint address range if the given address range is
already filled with non-swappable memory. Pages that can be swapped or
discarded can be allocated anywhere.

However, just looking at this table (which is by no means complete--
corrections and additions welcome!) it would seem that the most
straightforward strategy is to allocate all unswappable memory as high
in the address space as we can given the limitations of the hardware
that must access it. So kernel stack pages go at the very highest
addresses, and swappable pages or page cache go at the lowest addresses.

Zygo Blaxell, Linux Engineer, Corel Corporation. (work) or (play). Opinions above are my own, not Corel's.
Size of 'diff -Nurw [...] winehq corel' as of Thu Jun 3 13:14:00 EDT 1999
Lines/files: In 20094 / 98, Out 17319 / 152, Both 12093 / 142

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:52    [W:0.042 / U:2.896 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site