From owner-freebsd-hackers Wed Feb 17 10:44:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id 1DD5A113A9 for ; Wed, 17 Feb 1999 10:44:22 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 3461 invoked from network); 17 Feb 1999 18:44:18 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 17 Feb 1999 18:44:18 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id NAA69882; Wed, 17 Feb 1999 13:44:19 -0500 (EST) Message-Id: <199902171844.NAA69882@y.dyson.net> Subject: Re: vm_page_zero_fill In-Reply-To: <199902171838.LAA20158@usr07.primenet.com> from Terry Lambert at "Feb 17, 99 06:38:39 pm" To: tlambert@primenet.com (Terry Lambert) Date: Wed, 17 Feb 1999 13:44:19 -0500 (EST) Cc: dyson@iquest.net, tlambert@primenet.com, toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert said: > > > The thing that appalled me was what you said about BSS being zero'ed > > > in the kernel space using zeroed pages instead of as a result of an > > > explicit zeroing by the execution class loader. > > > > That is the way that it works. Explict zeroing is wasteful because > > it cannot easily take advantage of background prezeroing... However, > > recently prezeroed pages make for efficient usage of cache. The zero > > queue (and all others) are designed to take advantage of recent cache > > usage. > > This is robbing Peter to pay Paul; in a way. The base assumption > that you are hiding is that you aren't constrained by memory > bandwidth. This isn't true if you are nearly saturating a PCI > bus with 4 BT848's (to pick the highest memory bandwidth application > I know about). > Prezeroing doesn't take any significant CPU if there are no cycles available. It does increase latency slightly, if zeroing is allowed to happen. > > Maybe we need to go back to first principles, and examine the > assumptions about what constraints are in effect under various > usage models, and make trades like these optional instead of > mandatory. I think that's all he wants, anyway. > The prezeroing isn't adding any cost to him, the ability to support returning non-initialized data from the kernel would be useful. In that case, turning off prezeroing *might* help (but probably won't.) -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message