Date: Wed, 17 Feb 1999 14:23:50 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Kevin Day <toasty@home.dragondata.com> Cc: dyson@iquest.net, tlambert@primenet.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill Message-ID: <Pine.BSF.3.95.990217141349.15285L-100000@current1.whistle.com> In-Reply-To: <199902171902.NAA25290@home.dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Feb 1999, Kevin Day wrote: > > 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. theoretically clearing of memory pages should not generate any PCI traffic. The average architecture puts the memory on the processor side of the PCI bridge which means that memory cycles by the processor should not be passed to the PCI bus. If it is.. get better hardware! Having read you rdescription below, here are my questions/comments. This comes from the experience I have with large scale servers serving streams of high quality image data. What yo can do to fix your problem depends upon what the exact data-path of your product is.. I assume you have data arriving via DMA from a PCI device, being stored in a memory buffer, possibly manipulated by the processor, and sent out again via another PCI busmaster. Is this true? do you have your own hardware? can it be changed at all? do you have shared (PCI) memory on either the source or the destination? does the processor need to read the actual data (inline?) can you alter your 20 sub processes to stay resident and only start up once? (i.e. become daemons that accept work requests?) how much RAM on the machine, and how much buffer space do you require? etc. etc. > > 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 > 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?Pine.BSF.3.95.990217141349.15285L-100000>