From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f72.google.com (mail-it0-f72.google.com [209.85.214.72]) by kanga.kvack.org (Postfix) with ESMTP id 48BD56B0033 for ; Mon, 27 Nov 2017 04:08:52 -0500 (EST) Received: by mail-it0-f72.google.com with SMTP id t1so17091665ite.5 for ; Mon, 27 Nov 2017 01:08:52 -0800 (PST) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id w143sor6725158ita.54.2017.11.27.01.08.51 for (Google Transport Security); Mon, 27 Nov 2017 01:08:51 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20171127090414.ayp4s5bmizhetmis@dhcp22.suse.cz> References: <201711261938.BCD34864.QLVFOSJFHOtOFM@I-love.SAKURA.ne.jp> <20171127082112.b7elnzy24qiqze46@dhcp22.suse.cz> <20171127083707.wsyw5mnhi6juiknh@dhcp22.suse.cz> <20171127085220.kf6gyksfy276mkk6@dhcp22.suse.cz> <20171127090414.ayp4s5bmizhetmis@dhcp22.suse.cz> From: Yafang Shao Date: Mon, 27 Nov 2017 17:08:50 +0800 Message-ID: Subject: Re: [PATCH] mm: print a warning once the vm dirtiness settings is illogical Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Tetsuo Handa , Andrew Morton , Jan Kara , Linux MM , fcicq@fcicq.net 2017-11-27 17:04 GMT+08:00 Michal Hocko : > On Mon 27-11-17 16:54:39, Yafang Shao wrote: >> 2017-11-27 16:52 GMT+08:00 Michal Hocko : >> > On Mon 27-11-17 16:49:34, Yafang Shao wrote: >> >> 2017-11-27 16:37 GMT+08:00 Michal Hocko : >> >> > On Mon 27-11-17 16:32:42, Yafang Shao wrote: >> >> >> 2017-11-27 16:29 GMT+08:00 Yafang Shao : >> > [...] >> >> >> > It will help us to find the error if we don't change these values like this. >> >> >> > >> >> >> >> >> >> And actually it help us find another issue that when availble_memroy >> >> >> is too small, the thresh and bg_thresh will be 0, that's absolutely >> >> >> wrong. >> >> > >> >> > Why is it wrong? >> >> > -- >> >> >> >> For example, the writeback threads will be wakeup on every write. >> >> I don't think it is meaningful to wakeup the writeback thread when the >> >> dirty pages is very low. >> > >> > Well, this is a corner situation when we are out of memory basically. >> > Doing a wake up on the flusher is the least of your problem. So _why_ >> > exactly is this is problem? >> > -- >> >> Are you _sure_ this is the least of the problem on this corner situation ? > > I am not _sure_ and that is why I'm _asking_ _you_ and you seem to come > up with reasons which don't make me really convinced. > > If we wake up flusher which have nothing to do they will simply back > off. That is what have to do anyway because dirty data can be truncated > at any time, right? > Under this condition it is better not to wakeup the bdi writeback. That's why I return the min value 100 to avoid doing this. Maybe 100 is not enough. It should be geater IMHO. >> Why wakeup the bdi writeback ? why not just kill the program and flush >> the date into the Disk when we do oom ? > > I really do not see how this is related to the discussion here. OOM > killer doesn't flush anything. It kills a task and that is it. Moreover > we do not flush any data from direct context at all. We simply rely on > flushers to do the work. > -- That's my fault. Just killing the program is enough. Thanks Yafang -- 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/ . Don't email: email@kvack.org