From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 3 Feb 2005 22:50:28 -0800 (PST) From: Christoph Lameter Subject: Re: A scrub daemon (prezeroing) In-Reply-To: <1107499403.5461.32.camel@npiggin-nld.site> Message-ID: References: <1106828124.19262.45.camel@hades.cambridge.redhat.com> <20050202153256.GA19615@logos.cnet> <20050202163110.GB23132@logos.cnet> <16898.46622.108835.631425@cargo.ozlabs.ibm.com> <16899.2175.599702.827882@cargo.ozlabs.ibm.com> <1107499403.5461.32.camel@npiggin-nld.site> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Nick Piggin Cc: Paul Mackerras , Rik van Riel , Marcelo Tosatti , David Woodhouse , linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@osdl.org List-ID: On Fri, 4 Feb 2005, Nick Piggin wrote: > If you have got to the stage of doing "real world" tests, I'd be > interested to see results of tests that best highlight the improvements. I am trying to figure out which tests to use right now. > I imagine many general purpose server things wouldn't be helped much, > because they'll typically have little free memory, and will be > continually working and turning things over. These things are helped because zapping memory is very fast. Continual turning things over results in zapping of large memory areas once in awhile which even speeds up (a sparsely accessing) benchmark. Read my earlier posts on the subject. There is of course an issue if the system is continuously low on memory. In that case the buddy allocator may not generate large enough orders of free pages to make it worth to zap them. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: aart@kvack.org