Pavel Emelyanov <xemul@xxxxxxxxxxxxx> writes: > On 07/13/2012 08:57 PM, Miklos Szeredi wrote: >> Pavel Emelyanov <xemul@xxxxxxxxxxxxx> 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 Okay, maybe I'm blind but if this is true, then how is balance_dirty_pages() supposed to ensure that the per-bdi limit is not exceeded? > 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. That makes some sense, but it looks to me that FUSE, NFS and friends want a stricter dirty balancing logic that looks at the bdi thresholds even if the global limits are not exceeded. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
