I might be mis-reading what you are trying to say....
DMA needs _physically_ contigious memory, it doesn't use the CPUs MMU.
(At least on Intel. Not 100% sure what can be done with external MMUs,
but I guess DMA still works on physical and not virtual address otherwise
there would be all sort of problems).
If we can identify pages in the kernel which can be relocated, then yes
it is possible to create the necessary physical hole.
> Yes it's possible, and yes people are working on it (both myself and Mark
> Hemment are doing similar, but different implementations). However we do
> generally want to avoid these sorts of memory management tricks as
> otherwise one's system might end up spending a great deal of time
> shuffling pages around in memory. Any driver that needs to regularly
> allocate dmable pages should really think about doing that at startup,
> and just holding onto these flip buffers for its lifetime.
Hi Ben!
I've been disappointed in not seeing any responses to your original
mail, it certainly deserves some support and encouragement.
I've only quickly looked at your patch, but will look in more
detail later and give you some feed-back. (I might even steal some of the
ideas :)
Yes, my method is different but the underlying principle is the same
(having pte chains - I've built mine on top of clusters). I'm aiming more
towards servers, with only one eye on small desktop systems (small being
8MBs or less, which _generally_ need good swap handling. ie. a true
swap file-system which can work over networked file systems).
Except for when NFS is being used, 90% of page allocations are for
single pages (outside of an interrupt). So this is what I'm optimising
for (no cli()s for a page-allocation).
Selecting which pages to move/swap/destory to create a necessary
physical hole [for an allocation] is proving to be an interesting problem.
It appears to be a function of a page's age, and the age of physically
adjacent pages (a free page having a negative age). Unfortunately, I'm
not longer maintaining ages (ordered active and inactive list, with a page
referneced history bit plus pte(s) referneced bit seems to be just as
effective - and [surprisingly] lighter to maintain).
Regards,
markhe
------------------------------------------------------------------
Mark Hemment, Unix/C Software Engineer (Contractor)
markhe@nextd.demon.co.uk http://www.nextd.demon.co.uk/
"Success has many fathers, failure is a B**TARD!" - anon
------------------------------------------------------------------