Date: Thu, 21 Dec 2006 00:41:45 -0800 From: Suleiman Souhlal <ssouhlal@FreeBSD.org> To: Peter Grehan <grehan@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/powerpc/powerpc mmu_oea.c Message-ID: <458A48C9.40807@FreeBSD.org> In-Reply-To: <200612200110.kBK1AMeI091785@repoman.freebsd.org> References: <200612200110.kBK1AMeI091785@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Grehan wrote: > grehan 2006-12-20 01:10:21 UTC > > FreeBSD src repository > > Modified files: > sys/powerpc/powerpc mmu_oea.c > Log: > Remove bogus increment of re-hashed PTEG index. This snuck in with r1.12 of > pmap.c, and is potentially the cause of hangs reported on machines with a > small amount of memory. On machines with sufficient RAM, and without a lot > of processes running, this situation would probably never occur. > > Testing is still incomplete, but it is obviously wrong so remove the > offending code now. > > The issue of what to do when both the primary and secondary hash overflow > is still open. Could we just evict one random entry from either the primary or secondary PTEG and use that spot to insert the current PTE? (Isn't the whole point of pvo_entry to permit pages to be searched quickly if their virtual->physical mapping has already been computed before, basically making page faults to pages that have been evicted from their PTEGs very cheap (because we don't need to walk the vm_map entries etc again)?) Admittedly, I have forgotten the very few things I knew about powerpc, so I might be completely wrong. -- Suleiman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?458A48C9.40807>