From owner-freebsd-ppc Wed Feb 27 21:28:43 2002 Delivered-To: freebsd-ppc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 1AAC237B41A; Wed, 27 Feb 2002 21:28:40 -0800 (PST) Received: (from luoqi@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g1S5SeI00984; Wed, 27 Feb 2002 21:28:40 -0800 (PST) (envelope-from luoqi) Date: Wed, 27 Feb 2002 21:28:40 -0800 (PST) From: Message-Id: <200202280528.g1S5SeI00984@freefall.freebsd.org> To: benno@freebsd.org Subject: Re: cvs commit: src/sys/powerpc/powerpc pmap.c Cc: freebsd-ppc@freebsd.org Sender: owner-freebsd-ppc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 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