The important thing is to distinguish two kinds of pages, namely ones
holding kernel data structures (unswappable), and ones holding
user data (swappable) like the page cache.
Any kerel call may mess with a large number of the former, but
will generally not access many of the latter. First of all,
mapping it into user space or intiating DMA isn't access, so it
doesn't matter if it's not mapped in the kernel address space.
The only issues are zeroing pages, copying to/from user space,
PIO device drivers, and some reading of the data, like loading
executables.
The problem with those activities is that you have to map them
into kernel space to do thm, and that requires TLB invalidation
and shootdown, and that's slow.
Ah, but!...
It doesn't require TLB shootdown if you just decide to let the
mappings be per-processor. They're probably pretty transient
anyway, so just declare them to only be valid between calls to
schedule(). This gets rid of a *lot* of SMP cost.
It can also, if you're clever, avoid a need for TLB
invalidation. Allocate, say, a page of TLB mappings per processor.
If you think 1024 mappings isn't safely larger than your TLB, you
can make it bigger. Anyway, use the slots in round-robin order.
By the time you get around to using a slot again, you can be
sure that it has been flushed from the TLB so it will be reloaded
on first access without the need to get fancy.
(Um, is this true with every possible peeudo-LRU scheme?)
Thus, the time to intiailze access to a page is limited to
initializing one TLB slot plus one TLB miss. TLB misses are
annoyingly slow, but this doesn't seem *that* unreasonable.
And you can even support 2^36 bytes of memory this way.
Anyway, it's just mental masturbation, but I thought I'd throw it out.
-- -Colin- 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/