From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Wander MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17025.4213.255704.748374@gargle.gargle.HOWL> Date: Tue, 10 May 2005 15:50:13 -0400 Subject: Re: Fw: [Bug 4520] New: /proc/*/maps fragments too quickly compared to In-Reply-To: <20050510124357.2a7d2f9b.akpm@osdl.org> References: <20050510115818.0828f5d1.akpm@osdl.org> <200505101934.j4AJYfg26483@unix-os.sc.intel.com> <20050510124357.2a7d2f9b.akpm@osdl.org> Sender: owner-linux-mm@kvack.org Return-Path: To: Andrew Morton Cc: "Chen, Kenneth W" , wwc@rentec.com, mingo@elte.hu, arjanv@redhat.com, linux-mm@kvack.org List-ID: Andrew Morton writes: > "Chen, Kenneth W" wrote: > > > > Andrew Morton wrote Tuesday, May 10, 2005 11:58 AM > > > "Chen, Kenneth W" wrote: > > > > Andrew Morton wrote on Monday, May 09, 2005 2:27 PM > > > > > Possibly for the 2.6.12 release the safest approach would be to just > > > > > disable the free area cache while we think about it. > > > > > > > > I hope people are not thinking permanently kill the free area cache > > > > algorithm. It is known to give a large percentage of performance gain > > > > on specweb SSL benchmark. I think it gives 4-5% gain from free area > > > > cache algorithm. > > > > > > It also makes previously-working workloads completely *fail*. > > > > I agree that functionality over rule most of everything else. Though, I > > do want to bring to your attention on how much performance regression we > > will see if the free area cache is completely disabled. I rather make > > noise now instead of a couple month down the road :-) > > Well we allegedly have a patch from Wolfgang which fixes things up, but our > talk-to-testing ratio seems to be infinite. > > This is pretty serious, guys. Could someone please find the time to work > on it? I volunteer to do the testing - just the test I got from Ingo did not show any timing difference for either of the three solutions: a) use free_cache b) disable free_cache c) use my maybe improved and maybe much too complex free_cache The test_str02.c I got only ran up to 1300 threads on my machine (8GB dual x86_64) and Ingo expected it to go up to 20000. If there is any other test case I'm very willing to do the timing tests... Wolfgang -- 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