On Thursday 24 May 2001 11:33 am, Richard Earnshaw wrote:

> > Support the scheduler lock protocol (once I actually find out what that
> > is)
> >
> :-)  And then fix the open PR that's related to this...

Yep, first I need to figure out what the scheduler lock protocol is, I figure 
that looking at i386 and alpha should help, that and I'll mail Jason as he 
posted the PR :)

> > Make it SMP safe (hard to test, but we should be in case someone ever
> > does an SMP based arm box)
>
> Somewhat pointless at this time, particularly if it will impact
> performance.  Until the models for cache coherency on SMP ARM systems are
> defined it isn't really sensible to consider this (IMO).

Not so much a consideration, more related to locking, IE we might not have 
the locks etc in place, but I'd rather be able to come along later and add 
them if the need arises, eg hydra board

> > Make L1 tables for processes dynamic, IE get rid of the 256 hard limit
> > and other static limits around the place.
>
> Always sensible to avoid hard limits if possible.

Reading around it seems to relate to us not going over 4MB limit of 
something, although I can't see a reason why there is a limit, the 16k of L1 
table can be anywhere in memory as can the L2 tables.

> > Make use of pools where possible.
>
> Sounds good.

I'm thinking of the L1 tables.

> > Other suggestions.  (Note I'll be rummaging around other platform pmap's
> > to see how things are done)
>
> Make use of the new pmap_update() calls that Jason has added to defer
> options when possible until they are really needed (hopefully when the
> pmap in question isn't the current one).  Build work lists when we can and
> then manage them during the update calls.
>
> Investigate caching the L1/2 tables to improve performance.  May require
> restructuring most of the code...

Most definetly yes.

> Look at the way i386 pmap organises things -- it should be possible to
> significantly reduce the number of calls to pmap_pde/pmap_pte (which is
> currently huge)

I'm planning to rework anything that needs it, I won't claim to get it right 
first time and if I don't I'll hopefully understand why it's not right, and 
be able to figure out the right way to do things.

> I did send you my patches that I already have, didn't I?

Probably worth resending me them.  I've got them somewhere, but you might 
have changed them since.

Oh anyone know of any decent benchmarks for testing pmap?

Cheers,
Chris