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. zygob@corel.ca (work) or zblaxell@furryterror.org (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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/