Date: Wed, 17 Feb 1999 15:03:34 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: tlambert@primenet.com (Terry Lambert) Cc: dyson@iquest.net, tlambert@primenet.com, toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill Message-ID: <199902172003.PAA70095@y.dyson.net> In-Reply-To: <199902171858.LAA21748@usr07.primenet.com> from Terry Lambert at "Feb 17, 99 06:58:38 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert said: > > > 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. > > He's strapped on memory bandwidth, not CPU cycles. He's willing to > eat zeroing on in those cases where he has no choice because it > impacts base functionality. > If zeroing isn't allowed to happen, then there'll be no additional bandwidth used. > > > > 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.) > > Again, he's wanting to reclaim memory bandwidth from the prezeroing > of pages that are prezeroed not because they need to be, but for > security reasons that he doesn't care about. > That really doesn't make any (much) difference. Turning off prezeroing is easy anyway (sysctl.) -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902172003.PAA70095>