From owner-cvs-all@FreeBSD.ORG Thu Dec 21 13:41:07 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C37316A403; Thu, 21 Dec 2006 13:41:07 +0000 (UTC) (envelope-from ssouhlal@FreeBSD.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2967913C428; Thu, 21 Dec 2006 13:41:07 +0000 (UTC) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.0.100] (c-67-188-127-3.hsd1.ca.comcast.net [67.188.127.3]) by elvis.mu.org (Postfix) with ESMTP id 464351A4D88; Thu, 21 Dec 2006 00:42:27 -0800 (PST) Message-ID: <458A48C9.40807@FreeBSD.org> Date: Thu, 21 Dec 2006 00:41:45 -0800 From: Suleiman Souhlal User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Grehan References: <200612200110.kBK1AMeI091785@repoman.freebsd.org> In-Reply-To: <200612200110.kBK1AMeI091785@repoman.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/powerpc/powerpc mmu_oea.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2006 13:41:07 -0000 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