603 support

[Greg Alexander]

When I wrote this message I was a little hot, so it may come off as a
flame.  I've tried to edit out the flame parts, but don't take things
the wrong way.

Just so everyone's clear, I've read the chapter in the 603 user's manual
on memory management, and I'm farmiliar with PPC memory management, so
realize that I understand how the TLB exceptions on a 603 are supposed
to work.  I also realize that on the 603 specifically there is the
potential for reloading the TLBs without using hash tables, which can be
a performance benefit (indeed under linux, it is one.)

Now, from that standpoint...

Benjamin Herrenschmidt wrote:
> 
> >On Wed, May 01, 2002 at 12:45:44PM -0500, Greg Alexander wrote:
> >> 1.) Is there still a way to get the current MOL working with a 2.2.20
> >> kernel?  i.e. when did linux stop using page tables on the 603?
> >>
> >Hmm... I think it ought to work. The 603 code is present
> >in recent 2.2 kernels (but disabled by default). Change
> >
> >       #define NO_RELOAD_HTAB  1
> 
> To be precise, linux do use the page tables, it doesn't use the hash
> table.

It all depends on who you're talking to.  If you design PPCs for a
living, linux doesn't use the PPC page tables, but instead uses
something else entirely, call it a linux page table.  At any rate, I
accept that the convention in linux mailing lists is that the PPC page
table is called a hash table, and will try and remember to use that
terminology.

> Greg: what happens is that the 603 doesn't autmatically load PTEs
> from the hash table. Instead, it faults on TLB miss exceptions which
> are then responsible for loading the TLB appropriately.
> 
> The kernel 2.4 and the kernel 2.2 with NO_RELOAD_HTAB set to 1 will
> directly load the TLBs from the linux page tables. The kernel 2.2
> without the NO_RELOAD_HTAB "emulates" the hash table by using
> TLB miss exception vectors that do the hash table lookup.

I think this is being a little harsh.  It doesn't emulate the hash
table, it emulates the hardware to search the hash table.  In other
words, old kernel 2.2 does what the 603 was designed to do until we
figured out how to be sneaky and do something that provides better
performance.

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

> >to zero in arch/ppc/kernel/head.S and arch/ppc/mm/init.c
> >in order to activate it. To get mol running, you will
> >have to disable the 603 hooks (and the SDR1 manipulation).
> >
> >> 2.) The 603 problems seem to be related to telling linux that we've got
> >> a 603... why not tell it we're running a sort of 604 in a kernel patch?
> >> Then wouldn't it use "real" page tables?
> >
> >More or less, but the exception handlers for the 603 traps
> >are needed (those that are in the 2.2 kernel).
> 
> As I stated above, the 603 don't have the HW to lookup the hash
> table automatically.

Yes, but it's a matter of a few simple exception handlers.  If you put
the code in for those and do them right, the kernel doesn't have to be
any the wiser about the fact that it's software doing the lookups.  It
just gets told "put this memory here and keep it there," and that's all
it needs to know about the hardware not really supporting hash table
lookups.  That was the whole point of the 603 design.  Why spend the
area on something easily done in software?  If my understanding of the
performance difference of hash table lookups between the 603 and 604 is
correct, this was a good call, as the performance difference isn't that
big.

The trick that linux does happens to improve performance, but it wasn't
the original intention of the design.

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

GREG