Peter Jeremy <peterjeremy_at_optushome.com.au> writes:
> Finally, how many different bcopy/bzero variants to we want? A
> "page-size" variant has the advantage of not having to worry about
> alignment or remaining-bytes issues but doubles the number of
> bzero/bcopy variants we need to maintain. Likewise, different
> variants optimised for different feature sets of different CPUs
> in different families could very rapidly get out of hand.
I've attached an untested patch that sets up the infrastructure for
processor-specific pagezero() and pagecopy() on i386. At the very
least, it helps avoid some of the #ifdef spaghetti in pmap.c, and it
should also result in a slight speedup for page zeroing and copying.
(the patch builds, but I haven't booted it)
Note that this patch makes pmap_zero_page_area() identical to
pmap_zero_page() on i386 - this was already the case for i686-class
CPUs since they use i686_pagezero() for pmap_zero_page_area(). This
could turn out to be a pessimization on older CPUs with smaller
amounts of cache, but I don't think pmap_zero_page_area() is used a
lot, so it's probably not noticeable.
On a different note, support.s is a bloody mess. Once the dust has
settled, I'd like to go through it and reorder its contents a little.
Dag-Erling Smørgrav - des_at_ofug.org
Received on Sat Mar 29 2003 - 04:22:13 UTC