[parisc-linux] Switch console error.

[Matthew Wilcox]

On Tue, Mar 12, 2002 at 04:03:59PM -0800, Gururaj Ananthateerta wrote:
> well, this whole exercise was to contribute to parisc linux developement.
> well I got something to work on then.  Can u help me with sime jumpstarters.

sure.  here's the plan i had.  you may disagree...

The architecture guarantees us that pages which are mapped at the same
address, modulo 4MB, will be cache coherent.  We already take advantage
of this (see get_shared_area in arch/parisc/kernel/sys_parisc.c, called
via arch_get_unmapped_area from the mmap path).  So all user mappings of a
page are coherent.  What isn't coherent is the kernel's view of the page.

Before the kernel accesses a page which is in the page cache (all pages
which can be mmaped live in the page cache), it calls kmap() and after
it has finished accessing this page, it calls kunmap().  This scheme was
invented for the benefit of architectures which support more physical
memory then it has address lines for (eg PAE36 on x86).

So if we reserve a large chunk of the kernel's address space to map
page cache pages into temporarily with kmap, we can provide the kernel
with a coherent view of the page.  Superdome only supports 128GB ram,
so by reserving a 128TB chunk of address space (hey, we have plenty of
address space..)  we give each 4k page a 4MB space to be mapped in.

The obvious way to do it, which I've described to everyone up until
now is to do something like:

void *kmap(struct *page) {
	struct vm_area_struct *vma = page->mapping->i_mmap_shared;
	if (!vma)
		return page->virtual;
	return (void *) ((unsigned long) page->virtual << 10 | vma->vm_pgoff);
}

But I wonder whether it might not be feasible to simply adjust
page->virtual when changing the mapping of a page into userspace.
Something to investigate further.

This is the easy part of the solution.  The part I haven't even attempted
to describe is, what if we get a TLB miss?  See the assembly code for the
TLB miss handler in arch/parisc/kernel/entry.S, starting at dtlb_miss_20w:
You'd probably want to modify dtlb_check_alias_20w to check for this case
rather than insert a huge number of TLB entries.

-- 
Revolutions do not require corporate support.