From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 11:18:06 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1878D16A4EC; Tue, 16 Sep 2003 11:18:06 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id EADC643FE1; Tue, 16 Sep 2003 11:18:04 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfl2a.dialup.mindspring.com ([165.247.212.74] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19zKOp-0005a6-00; Tue, 16 Sep 2003 11:18:04 -0700 Message-ID: <3F6753AF.7CC03217@mindspring.com> Date: Tue, 16 Sep 2003 11:17:19 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott Long References: <3F66A446.7090408@freebsd.org> <20030916131622.N54869@news1.macomnet.ru> <3F672308.1080909@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a41e0c3a15d68781abc0d0c3bc7c226f322601a10902912494350badd9bab72f9c350badd9bab72f9c cc: Maxim Konovalov cc: current@freebsd.org Subject: Re: Release Engineering Status Report X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2003 18:18:06 -0000 Scott Long wrote: > Agreed. PAE was merged into -stable in three steps. Backing out the > third step and leaving the first two steps removes the instability. > Unfortunately, it was the third step that also was the most complex. > In any case, we have 2 weeks to find the resolution before the decision > must be made on keeping or tossing PAE. Since PAE is a *highly* > sought after feature, it would be doing a disservice to our user base > to remove it without putting in some effort to fix it. Not to be rude or anything, so please don't take it that way... Exactly why is PAE "...a *highly* sought after feature..."? It's not like it increases the KVA space for the kernel itself, or UVA space for individual processes. I could maybe understand if processes were no longer mapped into KVA on trap/system call entry, since that would cause the UVA and KVA to both go to the full 4G size, at some additional copying cost, which is (relatively) low on Intel, for the benefit of a larger virtual address space that would let you map more kernel data and/or run larger application working sets for things like databases. But as it is, it's basically nothing more than L3 cache, which has always been seen as being of dubious benefit (otherwise all machines would come with L3 caches). -- Terry