From patchwork Mon Mar 14 16:09:00 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Hocko X-Patchwork-Id: 8581201 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 80DD99F294 for ; Mon, 14 Mar 2016 16:09:08 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9A5FE203B4 for ; Mon, 14 Mar 2016 16:09:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7A12D203DA for ; Mon, 14 Mar 2016 16:09:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751392AbcCNQJE (ORCPT ); Mon, 14 Mar 2016 12:09:04 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:38576 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751371AbcCNQJD (ORCPT ); Mon, 14 Mar 2016 12:09:03 -0400 Received: by mail-wm0-f54.google.com with SMTP id l68so109466791wml.1 for ; Mon, 14 Mar 2016 09:09:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=sRoKZiesQJBLFjphXbTZmlg7DWoCwkNuydvy+BiLz08=; b=Ad7ADadT3B3zldld7Ocf9maPDyH4zNbPsxqQO83Bc+bEeBMpO5vVMaJlusfs8pzw4c kiGg78WMCJEBCO0148FF/jOT1kJpNumtX5g63cHz5SBAYh79E0lVxU2dlrQK86pchicP jeiLMqi0DJy9T4NxCELvgtg7F39FIe/h3/a1PaOfBDBAyi9T7PYDcft+7lod6Ra86WP0 A+Fg9MR1eIgzy46IGy4pRwy8v4odnFYWjAUN0Mvx/tACpdcbgDBNj/FZRtd2/pCKFA2J KX54sws0iMYm9R/gOsROawyd9sgzZyz0koHgr8p8OILNfJYl7bWkqtp1i3HE6BV4xyRz waIg== X-Gm-Message-State: AD7BkJJpcwVmV4K+giKhOjCAq4q9lEjXZ6ndVD+D7Qtv6W2kaqBsUu17ncjM8fxWaiDClQ== X-Received: by 10.194.60.165 with SMTP id i5mr28984216wjr.178.1457971742193; Mon, 14 Mar 2016 09:09:02 -0700 (PDT) Received: from localhost (nat1.scz.suse.com. [213.151.88.250]) by smtp.gmail.com with ESMTPSA id w188sm16740810wmw.19.2016.03.14.09.09.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Mar 2016 09:09:01 -0700 (PDT) Date: Mon, 14 Mar 2016 17:09:00 +0100 From: Michal Hocko To: Tetsuo Handa Cc: viro@zeniv.linux.org.uk, tj@kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] mm,writeback: Don't use memory reserves for wb_start_writeback Message-ID: <20160314160900.GC11400@dhcp22.suse.cz> References: <1457847155-19394-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> <201603132322.BEA57780.QMVOHFOSFJLOtF@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <201603132322.BEA57780.QMVOHFOSFJLOtF@I-love.SAKURA.ne.jp> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Sun 13-03-16 23:22:23, Tetsuo Handa wrote: [...] I am not familiar with the writeback code so I might be missing something essential here but why are we even queueing more and more work without checking there has been enough already scheduled or in progress. Something as simple as: > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c > index 5c46ed9..21450c7 100644 > --- a/fs/fs-writeback.c > +++ b/fs/fs-writeback.c > @@ -929,7 +929,8 @@ void wb_start_writeback(struct bdi_writeback *wb, long nr_pages, > * This is WB_SYNC_NONE writeback, so if allocation fails just > * wakeup the thread for old dirty data writeback > */ > - work = kzalloc(sizeof(*work), GFP_ATOMIC); > + work = kzalloc(sizeof(*work), > + GFP_NOWAIT | __GFP_NOMEMALLOC | __GFP_NOWARN); Well, I guess you are right that this doesn't sound like a context which really needs access to memory reserves and GFP_ATOMIC would more used for what can be achieved by GFP_NOWAIT now. Using __GFP_NOMEMALLOC would be needed regardless as you pointed out already because this might be called from the page reclaim context. So if the above simple hack or other explicit limit cannot be done then __GFP_NOMEMALLOC is an absolute minimum. > if (!work) { > trace_writeback_nowork(wb); > wb_wakeup(wb); > -- > 1.8.3.1 diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 6915c950e6e8..aa52e23ac280 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -887,7 +887,7 @@ void wb_start_writeback(struct bdi_writeback *wb, long nr_pages, { struct wb_writeback_work *work; - if (!wb_has_dirty_io(wb)) + if (!wb_has_dirty_io(wb) || writeback_in_progress(wb)) return; /*