603 support

mol-devel@lists.maconlinux.org mol-devel@lists.maconlinux.org
Thu, 2 May 2002 20:42:42 +0200


On Thu, May 02, 2002 at 07:50:19PM +0200, Benjamin Herrenschmidt wrote:
> >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. 
> 
> Well, SMP locking issues aren't that bad actually. I never
> found the time to go deep enough in my understanding of MOL low
> level MMU stuff, but it should only be a matter of taking the
> hash table lock when accessing the hash table or issuing tlbie's,

Yes. But taking the has lock requires MOL support in the
kernel proper. To be backward compatible we could optionally use
a private 64K page table. It doesn't require many lines of
code to implement...

If we take the kernel lock, we must put the complete hash
table operation in the kernel (e.g. insert PTE) since the
code holding the lock must be BAT mapped in order to
avoid deadlocks.

But what do we really need the kernel lock for? Clearly
PTE insertions must be protected, but what about zeroing
hash table entries or issuing tlbies? I remember having
seen some comment that the lock is needed for tlbie's,
but I don't really see why that is.

> though I'm not sure what MOL does regarding linux PTEs (do you
> touch them at all ?).

No. Well, MOL might overwrite PTEs at PTEG overflow but that 
is all.

> The VM somewhat relies on us properly
> setting PAGE_ACCESSED when putting things in the hash table on
> fault, and PAGE_HASHPTE should be set for a page that may be
> in the hash or the kernel flush code would fail to flush the
> page, but I beleive you have already that working.

Yes, that should be fully working.

/Samuel