context overflow

[David Edelsohn]

Paul,

	The POWER and PowerPC architectures specifically were designed
with the larger "virtual" address space in mind.  Yes, a single context
cannot see more than 32-bit address space at a time, but an operating
system can utilize that for more efficent access to a larger address
space.  Maybe the current HIGHMEM implementation is an anomaly, but it is
important to be open to these alternate perspecives.

	Also, as Dan said, the current PowerPC port is avoiding many of
the PowerPC architecture's design features for VMM.  While "mostly
incorrect use of the MMU" may be a little strong, I would agree with Dan
that the port is not using the PowerPC architecture as intended.  By not
utilizing the hardware assists, the port is not performing at its optimal
level.

	For instance, the rotating VSIDs are blowing away internally
cached information about mappings and forcing the processor to recreate
translations more often than necessary.  That causes a performance
degradation.  Pre-heating the TLB can be good under certain circumstances.

	As I have mentioned before, the current design appears to be
generating many hash table misses because it allocates a new VSID rather
than unmapping multiple pages from the page table.  This also means that
it cannot be exploiting the dirty bit in the page/hash table entry and
presumably encounters double misses on write faults.

	One really needs to consider the design model for the PowerPC
architecture and some of the microarchitecture optimizations utilizing the
greater chip area in newer PowerPC processor implementations to know how
to structure the PowerPC Linux VMM for best performance.  One needs to
consider these issues when arguing for a design to defer work (like TLB
entries) as well as considering the details of *how* the deferral is
implemented (VSID shuffling) relative to the perceived benefit.

	We really need to get more IBM PowerPC and kernel VMM experts
involved to explore the best design given the Linux kernel's abstractions
and limitations in the VMM space.

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/