Date: Wed, 27 Feb 2002 21:28:40 -0800 (PST) From: <luoqi@FreeBSD.org> To: benno@freebsd.org Cc: freebsd-ppc@freebsd.org Subject: Re: cvs commit: src/sys/powerpc/powerpc pmap.c Message-ID: <200202280528.g1S5SeI00984@freefall.freebsd.org>
index | next in thread | raw e-mail
> benno 2002/02/27 18:45:10 PST
>
> Modified files:
> sys/powerpc/powerpc pmap.c
> Log:
> Remove most of the usage of critical_enter/exit.
>
> I put these in to match the use of spl*() in the NetBSD
> code I was basing this
> on, but it appears to cause problems.
>
> I'm doing this in a separate commit so as to be able to
> refer back if locking
> becomes an issue at a later stage.
>
> Revision Changes Path
> 1.15 +0 -29 src/sys/powerpc/powerpc/pmap.c
(unrelated to this particular commit)
It was a fine idea to have a merged pv_entry and overflow structure,
and use the pv table kind of as the complete page table, and the hash
table its cache. I would guess this is probably where the speed-up
comes from.
But to traverse the linked pvo list in real mode (spill handler)
means the link pointers have to be a physical address. In the new
NetBSD code, this is done by allocating the pvo structures from
below 256M, which is mapped by BAT entry PA==VA.
In FreeBSD, the zone allocator won't do this job, first, you are
not guaranteed to get page below 256M, second, kva returned from
zalloc does not necessarily equal to pa (you don't really need the
kva). You'll have to write you own allocator. The tricky part is
how to allocate page below 256M. We could probably do something
similar to contigmalloc(), but my impression is this call could
be quite expensive. Especially so if we adopt a merged pvo struct,
because pv_entry allocation is much more frequent than overflow.
Maybe we could find a middle ground somewhere. For example, use
a separate overflow structure allocated from low memory when there
is a collision, but also keep a copy of pte data in pv_entry as well.
-lq
PS: sorry about a previous incomplete message, i was having some
trouble with our email server.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ppc" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202280528.g1S5SeI00984>