From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f198.google.com (mail-pf0-f198.google.com [209.85.192.198]) by kanga.kvack.org (Postfix) with ESMTP id 47C5F6B0033 for ; Mon, 27 Nov 2017 04:04:19 -0500 (EST) Received: by mail-pf0-f198.google.com with SMTP id 26so24378942pfs.22 for ; Mon, 27 Nov 2017 01:04:19 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id t134si828387pgc.384.2017.11.27.01.04.18 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 27 Nov 2017 01:04:18 -0800 (PST) Date: Mon, 27 Nov 2017 10:04:14 +0100 From: Michal Hocko Subject: Re: [PATCH] mm: print a warning once the vm dirtiness settings is illogical Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Yafang Shao Cc: Tetsuo Handa , Andrew Morton , Jan Kara , Linux MM , fcicq@fcicq.net 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? > 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. -- Michal Hocko SUSE Labs -- 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