From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Emelyanov Subject: Re: [PATCH 10/10] mm: Account for WRITEBACK_TEMP in balance_dirty_pages Date: Mon, 16 Jul 2012 07:27:55 +0400 Message-ID: <50038A3B.4090405@parallels.com> References: <4FF3156E.8030109@parallels.com> <4FF3166B.5090800@parallels.com> <87obnj38g9.fsf@tucsk.pomaz.szeredi.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "fuse-devel@lists.sourceforge.net" , Alexander Viro , linux-fsdevel , James Bottomley , Kirill Korotaev To: Miklos Szeredi Return-path: Received: from mailhub.sw.ru ([195.214.232.25]:21870 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751723Ab2GPD2M (ORCPT ); Sun, 15 Jul 2012 23:28:12 -0400 In-Reply-To: <87obnj38g9.fsf@tucsk.pomaz.szeredi.hu> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 07/13/2012 08:57 PM, Miklos Szeredi wrote: > Pavel Emelyanov writes: > >> Make balance_dirty_pages start the throttling when the WRITEBACK_TEMP >> counter is hight ehough. This prevents us from having too many dirty >> pages on fuse, thus giving the userspace part of it a chance to write >> stuff properly. >> >> Note, that the existing balance logic is per-bdi, i.e. if the fuse >> user task gets stuck in the function this means, that it either >> writes to the mountpoint it serves (but it can deadlock even without >> the writeback) or it is wrting to some _other_ dirty bdi and in the >> latter case someone else will free the memory for it. > > This is not just about deadlocking. Unprivileged fuse filesystems > should not impact the operation of other filesystems. I.e. a fuse > filesystem which is not making progress writing out pages shouln't cause > a write on an unrelated filesystem to block. > > I believe this patch breaks that promise. Hm... I believe it does not, and that's why. When a task writes to some bdi the balance_dirty_pages will evaluate the amount of time to block this task on based on this bdi dirty set counters. The global stats are only used to a) check whether this decision should be made at all and b) evaluate the dirty "fraction" of a bdi. That said, even if we stop the fuse daemon (I actually did this) other filesystems won't lock. The global counter would be high, yes, but the dirty set fraction of non-fuse bdi would be low thus allowing others to progress. > Thanks, > Miklos