Messages in this thread | | | Date | Fri, 8 Aug 1997 10:55:16 +0100 (BST) | From | Bryn Paul Arnold Jones <> | Subject | Re: Kernel virtual memory? |
| |
-----BEGIN PGP SIGNED MESSAGE-----
On Fri, 8 Aug 1997, Rauli Ruohonen wrote: > >> Sometime Rauli Ruohonen wrote: > >> DMA memory could be allocated by moving allocated blocks away from the > >> lower 16MB, and other parts of kernel could be made happy by changing the > >> page tables accordingly. [...] > > Yes yes yes yes, but you need the memory where the data is transferred > to/from and it must reside below 16MB, if the lower 16MB is full you can't > allocate DMA buffers! Thus when you insmod a module you may get errors that > "can't alloc dma memory" or similar. That's why those pages should be moved > out of the way! And no, I don't mean that if this kind of feature is added > coders should begin doing something idiotic like this: > > alloc_dma_mem(); > begin_dma(); > > interrupt_handler() { if(dma_done) free_dma_mem(); } > > Just to clarify, the DMA part of this suggestion is only for those rare > situations when ftape/floppy driver shouts that it can't alloc DMAable page. > The main point was that the memory fragmentation would no longer be an > issue, and I think that this would remove some kludges.. At least that's > what I gathered from the SLAB discussion, *I* haven't looked at that part of > the code so the kludges part is just wild guessing.. :) > > I hope you guys now understand what I mean, so you can tell me if it'll work > :^) >
Hmm, do you mean: 1. Use the CPU VM hardware to make a virtual address physically be <16M (but there's no real point, except to make a bounce buffer that doesn't cost any coping).
2. Use the CPU VM hardware to make several virtual ranges be the same physical one (Please no one talk about this).
3. Move a chunk of memory from <16M, and use the VM hardware to make it appear unmoved so you need not find/fix all references to it.
I'm assuming 3 as 1 is only helpful in one case (I can think of), and 2 is generally unhelpful IMHO.
You could then have something like this happening:
buf=kmalloc(some_memory, GFP_BUFFER); make_dmaable(buf, some_memory); trigger_dma(); unmake_dmaable(buf, some_memory); ... kfree(buf);
Probably be a real pain to implement tho.
> -- > Air is water with holes in it. > Bryn - -- PGP Pub key http://www.gytha.demon.co.uk/pubkey.asc ID: 1024/30AF2D69 On-line, adj.: FP: FC 4E 41 9E 64 C3 AB 28 A3 5A 57 F8 CC D9 A7 B8 The idea that a human being should always be accessible to a computer.
-----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Probably (spelt 'Proberbly') requires PGP version 2.6 or later ;)
iQCVAwUBM+rtCusaGi8wry1pAQFB2QQAowUSLcHz7/2t6cYym8VPc1RQzDAezPVu cBJVG9rSacBab/e7wy6gQmVRI7DtGhOBJ5iSksDDRbpZZy7GRNyrr35phfxgGDGR CvInI8k/ixSYxjmqvjPJ/nfHKnSeLmd+7JVvMCB4z+S5XA1sTRjRCgO5fLWDA4sm aSS3kYs/wS0= =KP5V -----END PGP SIGNATURE-----
| |