603 support

[mol-devel@lists.maconlinux.org]

On Thu, May 02, 2002 at 09:56:59AM -0500, Greg Alexander wrote:
> > The performance of the whole kernel is much better when loading the
> > TLBs directly from the linux page tables, so it would be better
> > to make MOL work with it instead of relying on the old behaviour.
> 
> I agree.  But it currently fails to work, doesn't it?  :)
> 
> I realize that forcing the kernel to use hash tables on the 603 is a
> hack, as they were removed for a reason.  This would be a quick fix
> until the real code was fixed.

Well, it would be good to verify that MOL still works on the 603
with the PTE hash enableded.

As for getting MOL running without the need for kernel PTE hash
support, I see two possibilities:

i) Fixing the current code. I believe it is close to functioning,
but since I didn't have a 603 at hand, I could never test it.

ii) Bypassing the use of the hash altogether. There might
be performance advantages with this, but for the sake of
simplicity and maintainability, I believe it might be better
to use a private hash table for MOL, which essentially
amounts to i).

Besides, I think I'll use a private hash table for the Darwin
implementation as well. In Linux it is relatively simple to share
the hash table since it is only used as a cache. Darwin relies
more on PTEs not getting flushed by MOL. The VSID namespace
must still be shared though, since flushing TLBs at context
switch is way to expensive.

As a side note, I think a private TLB might be a good thing
on SMP systems too in order to sidestep locking issues,
at least as a short term solution. 

> At any rate, I'll see what I can do to improve things.

It should be relatively easy to debug the current code.
If you insert a couple of 

	DEBUGGER(num) / DEBUGGER_SAVE(num)

statements in the exception handlers and fire up mol in
debugger mode, you should be able to see what is going on. 
(It is safe to use these statements almost anywhere.)

Cheers,

/Samuel