From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <405120FD.1030807@cyberone.com.au> Date: Fri, 12 Mar 2004 13:31:25 +1100 From: Nick Piggin MIME-Version: 1.0 Subject: Re: blk_congestion_wait racy? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Martin Schwidefsky Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org List-ID: Martin Schwidefsky wrote: > > > >>Yes, sorry, all the world's an x86 :( Could you please send me whatever >>diffs were needed to get it all going? >> > >I am just preparing that mail :-) > > >>I thought you were running a 256MB machine? Two seconds for 400 megs of >>swapout? What's up? >> > >Roughly 400 MB of swapout. And two seconds isn't that bad ;-) > > >>An ouch-per-second sounds reasonable. It could simply be that the CPUs >>were off running other tasks - those timeout are less than scheduling >>quanta. >> > >I don't understand why an ouch-per-second is reasonable. The mempig is >the only process that runs on the machine and the blk_congestion_wait >uses HZ/10 as timeout value. I'd expect about 100 ouches for the 10 >seconds the test runs. > >The 4x performance difference remains not understood. > > It would still be blk_congestion_wait slowing things down, wouldn't it? Performance was good when you took that out, wasn't it? And it would not unusual for you to be waiting needlessly without seeing the ouch. I think I will try doing a non-racy blk_congestion_wait after Jens' unplugging patch gets put into -mm. That should solve your problem. -- 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