From owner-freebsd-arch Wed Feb 14 16:19:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id B057137B4EC for ; Wed, 14 Feb 2001 16:19:29 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id RAA29578; Wed, 14 Feb 2001 17:14:32 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAAqpaaB5; Wed Feb 14 17:14:12 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA09453; Wed, 14 Feb 2001 17:18:58 -0700 (MST) From: Terry Lambert Message-Id: <200102150018.RAA09453@usr08.primenet.com> Subject: Re: sparse core dumps To: des@ofug.org (Dag-Erling Smorgrav) Date: Thu, 15 Feb 2001 00:18:53 +0000 (GMT) Cc: bde@zeta.org.au (Bruce Evans), dfr@nlsystems.com (Doug Rabson), arch@FreeBSD.ORG In-Reply-To: from "Dag-Erling Smorgrav" at Feb 14, 2001 12:46:52 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > One reason is that it is a bug for PAGE_SIZE to be visible to applications. > > Fair enough. That's like saying that it's a bug for alignment boundaries to be visible to the application (which they are, on architectures where unaligned accesses result in faults, either because of the fault causing a failure, or because of the fault being detectable through profiling aligned vs. unaligned access, and therefore detecting the fixup). Having the page size is useful information, so that cross-platform or cross architecture (on a single platform) applications can make good decisions. For example, a naieve program would buffer at the preferred block size on an audio CDROM, whereas a smart program will realize that the data will be loaded into page buffers, in order to ensure against having to reread data already loaded into cache, and to minimize the number of real faults, which might break up audio playback (same for DVDs). Similarly, databases and other mmap-using code have need of the information, for optimization purposes. You really can't hide the page size, and more than you can hide alignment boundaries, or any of a dozen other hardware artifacts that affect performance, if handled suboptimally (register windows and their effect on call stack depth and stack frame pushing vs. signal and longjmp behaviour, register window flushing as a result of user space threads context switches, etc., etc.). Now if you wanted to change that to say "./..it is a bug for applications to externalize behaviour that makes page size visible", then you _might_ have an argument (one could still argue about optimim pipe data blocking, between peers). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message