Re: Linux and physical memory

Jakub Jelinek (jj@sunsite.ms.mff.cuni.cz)
Tue, 19 Jan 1999 08:37:54 +0100 (CET)

> Jakub, you forget one important thing, and something we have been
> doing on sparc64 for some time now (not to support a lot of memory,
> but for performance, to eliminate some TLB thrashing).
>
> Anonymous pages aren't an issue at all if you can directly and
> efficiently load/unload TLB mappings in software like we can on
> sparc64. In fact, for sparc64, it is more efficient to (and we do):

I think I've mentioned that possibility in my post already, it would be
something like mmu_get_scsi_one/mmu_release_scsi_one on sun4d.
There are two major problems I can see. You need to modify page tables on
Intel and then go and flush them, which is kinda slow on x86 (someone
correct me if there is some fast method). Also, if you add PG_highmem, I bet
current page_alloc will suck badly (even the way how is PG_dma done now is
very unefficient). I think in 2.3 we should page_alloc should be rewritten
so that it can cope with multiple different classes of pages and allocate
them quickly. It should have some notion of class requirement or class
recommendation. So you could say I require a DMAble page, or give me a
non-DMAble page prefered, but if you only have DMAble, then give that to me.
It would be a win even for x86 floppy drivers, you wouldn't get out of DMA
so quickly.
Also, when I started thinking about Linux DR, actually just the memory
hotplug I'd definitely like to see in 2.4, I guess we'll need
PG_rellocatable to indicate a page address is stored only in page tables of
some tasks, so that kernel could swap/move them out if necessary.
The whole area of mem_map will be such place in Linux/sparc64, as we
definitely cannot abandon the idea of freeing unused mem_map parts (think
about .5G wasted on some E10k configurations, even if they could have 1G of
RAM (unlikely, but possible)), but if someone inserts a board in, we'll have
to use the mem_map. We could do some indirection in MAP_NR, but I guess we'd
loose performance badly. Current page_alloc cannot scale with multiple
class requirements, so neither PG_highmem, nor PG_rellocatable can be done
at the moment, IMHO.

Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/
Linux version 2.2.0-pre7 on a sparc64 machine (3958.37 BogoMips)
___________________________________________________________________

-
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/