Date: Thu, 15 Feb 2001 00:18:53 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: des@ofug.org (Dag-Erling Smorgrav) Cc: bde@zeta.org.au (Bruce Evans), dfr@nlsystems.com (Doug Rabson), arch@FreeBSD.ORG Subject: Re: sparse core dumps Message-ID: <200102150018.RAA09453@usr08.primenet.com> In-Reply-To: <xzpd7cltrkj.fsf@flood.ping.uio.no> from "Dag-Erling Smorgrav" at Feb 14, 2001 12:46:52 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102150018.RAA09453>