Re: Kernel virtual memory?

Mark Hemment (
Fri, 8 Aug 1997 00:11:00 +0100 (BST)

On Thu, 7 Aug 1997, Benjamin C R LaHaise wrote:
> On Thu, 7 Aug 1997, Rauli Ruohonen wrote:
> > Could kernel use virtual memory hardware to make non-linear chunks of
> > memory to look linear? It seems to me that it could solve the problems
> > with memory fragmentation and DMA memory allocation.
> >
> > 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.
> >
> > So, is this possible/feasible/too ugly to implement?

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).



Mark Hemment, Unix/C Software Engineer (Contractor)
"Success has many fathers, failure is a B**TARD!" - anon