From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [PATCH 0/2] Make task doing heavy writing killable Date: Mon, 14 Nov 2011 13:24:15 +0100 Message-ID: <20111114122415.GD5230@quack.suse.cz> References: <1321269030-6019-1-git-send-email-jack@suse.cz> <20111114115912.GA3224@localhost> <20111114120546.GA31037@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Wu Fengguang , Jan Kara , "linux-fsdevel@vger.kernel.org" , Al Viro , "k-mio@sx.jp.nec.com" , Andrew Morton To: Christoph Hellwig Return-path: Received: from cantor2.suse.de ([195.135.220.15]:55327 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752492Ab1KNMYh (ORCPT ); Mon, 14 Nov 2011 07:24:37 -0500 Content-Disposition: inline In-Reply-To: <20111114120546.GA31037@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon 14-11-11 07:05:46, Christoph Hellwig wrote: > On Mon, Nov 14, 2011 at 07:59:12PM +0800, Wu Fengguang wrote: > > On Mon, Nov 14, 2011 at 07:10:28PM +0800, Jan Kara wrote: > > > > > > Hello, > > > > > > these two patches aim at making task waiting in balance_dirty_pages() > > > killable. This is desirable because otherwise if filesystem stops accepting > > > writes (e.g. if device has been removed or other serious error condidion) we > > > have a task stuck in D state forever. > > > > Agreed totally. I myself has run into such conditions and get very > > annoyed not being able to kill the hard throttled tasks -- they just > > stuck there for ever if the error condition does not change. > > > > > I'm not sure who should merge these two patches... Al, Fengguang? > > > > I'd like to do it -- otherwise there will obviously be merge conflicts. > > > > Actually I also queued a patch to do this (attached). Your patches do > > better on TASK_KILLABLE and the use of signal_pending() in write > > routines, while mine goes further to add the break to various > > filesystems. How about combining them together? > > Can you make balance_dirty_pages(_ratelimited) return an error instead > of opencoding the fatal signal check everywhere? That would make the > interface a bit more obvious. We can do this. It's just that signal_pending() check e.g. in generic_perform_write() has a sense even when balance_dirty_pages() will be returning error because it also catches other cases... Honza -- Jan Kara SUSE Labs, CR