From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51]) by kanga.kvack.org (Postfix) with SMTP id 024D28D0041 for ; Thu, 17 Mar 2011 18:12:03 -0400 (EDT) Message-ID: <4D8286F9.7050107@fiec.espol.edu.ec> Date: Thu, 17 Mar 2011 17:11:05 -0500 From: =?ISO-8859-1?Q?Alex_Villac=ED=ADs_Lasso?= MIME-Version: 1.0 Subject: Re: [Bugme-new] [Bug 31142] New: Large write to USB stick freezes unrelated tasks for a long time References: <20110315135334.36e29414.akpm@linux-foundation.org> <4D7FEDDC.3020607@fiec.espol.edu.ec> <20110315161926.595bdb65.akpm@linux-foundation.org> <4D80D65C.5040504@fiec.espol.edu.ec> <20110316150208.7407c375.akpm@linux-foundation.org> <4D827CC1.4090807@fiec.espol.edu.ec> <20110317144727.87a461f9.akpm@linux-foundation.org> In-Reply-To: <20110317144727.87a461f9.akpm@linux-foundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: avillaci@ceibo.fiec.espol.edu.ec, bugzilla-daemon@bugzilla.kernel.org, bugme-daemon@bugzilla.kernel.org, linux-mm@kvack.org, Mel Gorman El 17/03/11 16:47, Andrew Morton escribio: > > ah, the epic 12309. https://bugzilla.kernel.org/show_bug.cgi?id=12309. > If you're ever wondering how much we suck, go read that one. > > I think what we're seeing in 31142 is a large amount of dirty data > buffered against a slow device. Innocent processes enter page reclaim > and end up getting stuck trying to write to that heavily-queued and > slow device. > > If so, that's probably what some of the 12309 participants are seeing. > But there are lots of other things in that report too. > > > Now, the problem you're seeing in 31142 isn't really supposed to > happen. In the direct-reclaim case the code will try to avoid > initiation of blocking I/O against a congested device, via the > bdi_write_congested() test in may_write_to_queue(). Although that code > now looks a bit busted for the order>PAGE_ALLOC_COSTLY_ORDER case, > whodidthat. > > However in the case of the new(ish) compaction/migration code I don't > think we're performing that test. migrate_pages()->unmap_and_move() > will get stuck behind that large&slow IO queue if page reclaim decided > to pass it down sync==true, as it apparently has done. > > IOW, Mel broke it ;) > I don't quite follow. In my case, the congested device is the USB stick, but the affected processes should be reading/writing on the hard disk. What kind of queue(s) implementation results in pending writes to the USB stick interfering with I/O to the hard disk? Or am I misunderstanding? I had the (possibly incorrect) impression that each block device had its own I/O queue. -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org