Subject: Re: Things to work on
To: Chris Gilbert <email@example.com>
From: Richard Earnshaw <firstname.lastname@example.org>
Date: 05/24/2001 11:33:33
> With it being a bank holiday this weekend (I think it's a bankholiday...) I'm
> thinking of getting on and playing with the pmap.c, however I'm just
> wondering if this is still needed and what features need to be allowed for?
> Current list:
> Has to be fast
But of course.
> Support the scheduler lock protocol (once I actually find out what that is)
:-) And then fix the open PR that's related to this...
> 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).
> 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.
> Make use of pools where possible.
> Be capable of doing some of the cleanup functionality.
> 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...
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
I did send you my patches that I already have, didn't I?