From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wu Fengguang Subject: Re: deadlock balance_dirty_pages() to be expected? Date: Fri, 7 Oct 2011 21:37:34 +0800 Message-ID: <20111007133733.GA6399@localhost> References: <4E8EF1D9.8050700@itwm.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "linux-fsdevel@vger.kernel.org" , Jan Kara , Peter Zijlstra To: Bernd Schubert Return-path: Received: from mga14.intel.com ([143.182.124.37]:47524 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965410Ab1JGNhh (ORCPT ); Fri, 7 Oct 2011 09:37:37 -0400 Content-Disposition: inline In-Reply-To: <4E8EF1D9.8050700@itwm.fraunhofer.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi Bernd, On Fri, Oct 07, 2011 at 08:34:33PM +0800, Bernd Schubert wrote: > Hello, > > while I'm working on the page cached mode in FhGFS (*) I noticed a > deadlock in balance_dirty_pages(). > > sysrq-w showed that it never started background write-out due to > > if (bdi_nr_reclaimable > bdi_thresh) { > pages_written += writeback_inodes_wb(&bdi->wb, > (write_chunk); > > > and therefore also did not leave that loop with > > if (pages_written >= write_chunk) > break; /* We've done our duty */ > > > So my process stay in uninterruptible D-state forever. If writeback_inodes_wb() is not triggered, the process should still be able to proceed, presumably with longer delays, but never stuck forever. That's because the flusher thread should still be cleaning the pages in the background which will knock down the dirty pages and eventually unthrottle the dirtier process. > Once I added basic inode->i_data.backing_dev_info bdi support to our > file system, the deadlock did not happen anymore. What's the workload and change exactly? > So my question is simply if we should expect this deadlock, if the file > system does not set up backing device information and if so, shouldn't > this be documented? Such deadlock is not expected.. Thanks, Fengguang