Date: Wed, 17 Feb 1999 13:02:27 -0600 (CST) From: Kevin Day <toasty@home.dragondata.com> To: dyson@iquest.net Cc: tlambert@primenet.com, dyson@iquest.net, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill Message-ID: <199902171902.NAA25290@home.dragondata.com> In-Reply-To: <199902171844.NAA69882@y.dyson.net> from "John S. Dyson" at "Feb 17, 1999 1:44:19 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.) > I'm kinda surprised at the traffic my post generated, but I'm being bound by secrecy restraints to say much more than what I can here. I do really appreciate the help you're giving me though... The system I'm working on is a embedded, highly graphical 2D/3D product. These systems will not be connected to the internet, nor will anyone have keyboard/telnet/terminal/whatever access to them. They're about as secure as they're going to get, so my concerns are mostly speed over security. In looking with some logic analyzers, we're seeing that we're nearly out of PCI bandwidth, and we're hitting the memory very hard too. 99% of our run time is spent ferrying data from ram into the graphic device. Because of the nature of the product, we're needing more and more 'real-time' like operation. The delay from when a user does something, until he/she sees it on the screen is critical, as well as being able to handle many input devices, and radically change the scheduler's behavior when something 'interesting' comes in. (My current kludge for really really important data that must flow between a few processes quickly is mucking with rtprio, which is working, but I'd prefer to have much more control over the scheduler). After things still being slower than I wanted, I pulled out a logic analyzer. In watching memory accesses on the analyzer, we saw a lot of zeroing going on, especially after exec()'ing another application. (This system has one supervisory process, that will start any one of 20ish other applications, in response to what the user wants to do). Currently, the time spent loading/preparing the new application is a bit long, so I was looking at ways to shrink that down. That's where this discussion came from. While I don't want to get accused of not trying to figure this one out on my own.... Suppose I mmap a large (2MB or more) file. Should any zero'ing be going on when I touch those pages for the first time? From the analyzer, it looks like it's zeroing pages before putting what it read from the disk into them, but as you know, figuring out what's really going on by watching a logic analyzer is a form of witchcraft... If this is the case, turning this off would greatly help me. :) (If I'm not being clear enough, imagine mmap'ing a movie, and memcpy'ing it into a frame buffer at 60fps, to get an idea of the kind of data I'm going through) I hope this sort of explained my application, although I'm sure there are arguments either way if this is really going to help me or not. Thanks again, Kevin 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?199902171902.NAA25290>