From patchwork Thu Feb 14 12:49:08 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 158362 Delivered-To: patch@linaro.org Received: by 2002:a02:48:0:0:0:0:0 with SMTP id 69csp1324508jaa; Thu, 14 Feb 2019 04:49:57 -0800 (PST) X-Google-Smtp-Source: AHgI3IYykBwbTQP/XpItkIm3Q5Iqpgaxnuxml+3wqR5a3HCAjsOYe1OonBTHLt/q3YI65s+W4mYx X-Received: by 2002:a63:61d8:: with SMTP id v207mr3622790pgb.308.1550148596964; Thu, 14 Feb 2019 04:49:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550148596; cv=none; d=google.com; s=arc-20160816; b=n9xOKfkQrmC6W8J7LUHchdyhV72FSuPIRjZ/K45UM1lHgowfUVd2o61XN5Ilm0LRHI 6FWVU3OQ3Tq/z2GUUP/RiWicCZMZ7si9Rvfrwxt1LBtabwH4Mqo93U/rlfTVh9duAbIp ovJGzVDBLNCHjWcY/jtLSi0KHGF8ju5hSdTWv7PMii6UU2g+Vcw/vDdg++oCoItfI264 rAuHq/8VMJd6XKiEJFdTlr/MzHqXWqKxfqjQdBUfosVIBQ9i9xjXY4OLYJGWPocUvNZ6 xhC/JZ6nPs+Cc/bXF/ugm8VFFDntNegQ+BaPj9fSUu4qmx5mEVL+3yBroMzd4DQwIw6x Zv8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=FBwDVBVidpKRU12BmkXiJ8IfZ5As+ofjPPWCh/WKTFI=; b=gVmp7VzvUHR0Ic65wyWtSRDHyHGl+xc9UUYlFHQSyh8cDcZoK9+LUOtiC/NIwoy6Gp p8aPXMgObaJqdPE3ylZER10TmQJuRZ6BzA9t0FA4uvjw9HuZlgj/CSG43W6SsxEBr8+b FL5Hihe/A7M3RnnW21Uf1VF+Lavg0kayvQvHAg7L9qoS3J+IAtwMi5qyLKINUjF6xHIp h5To07VZFWXkz6yPjgN/AAEA+CC/mzJTRqYwnrg+JIHh4GBXhO/yAVSyTK6gmG/4s4np OyTy5SHoNCBNyk8OgmNe0M7wf25cMVV7uDQkg7c+mmptueOuqCntGiCbK3kRh8N4h+GM IkEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=uzvuJ5R3; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g26si2310745pfi.184.2019.02.14.04.49.56; Thu, 14 Feb 2019 04:49:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=uzvuJ5R3; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2438535AbfBNMt4 (ORCPT + 15 others); Thu, 14 Feb 2019 07:49:56 -0500 Received: from mail-lj1-f193.google.com ([209.85.208.193]:42067 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2438534AbfBNMtz (ORCPT ); Thu, 14 Feb 2019 07:49:55 -0500 Received: by mail-lj1-f193.google.com with SMTP id l7-v6so5108444ljg.9 for ; Thu, 14 Feb 2019 04:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=FBwDVBVidpKRU12BmkXiJ8IfZ5As+ofjPPWCh/WKTFI=; b=uzvuJ5R33xqzg1LEYMpcjciQ7h8OQvjUHBpVDN31tVUndmUgcPC4tnHYOIvbuhT1Mj 3W/mBWqd/k599T0VPvreKAvddMC+pEVPCfngMr/hcEEwp7jRsPVJuXozSOEQycv92bPl 8zeCWsAsb3f1xgwvosYaORFrYb6VjuXRG6WU1PXVhsYWBJ9dq9/Q+16k8yRIMjINzpTK N1MmuACyCm8WnR0++fT1m936f9Pc50CWGuejbul4GPi8a16sMAtjtiwSWL0VfNjJFFBV d3bvIhD5Wv1iSH806YkVVtfPEYcZdJo8k+j/nENU+AMbXoaB7ghRKiSUiqgdfk87QFdy lYeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=FBwDVBVidpKRU12BmkXiJ8IfZ5As+ofjPPWCh/WKTFI=; b=hzTnJJcOoiPnFLI8uqmLHj0OekPRDz3/UD3sYSMMLvt39ZMN9OD27JpHyESjPgLS0N 1JK+wp5GSnJ4R9AtV9G19q0SNwtQc00EiFFCC8ddblcutzS6sSanm+bdSW63anTSGWSf wMTdXifxOeNGv7aTKzigYYUkU04W5KgU8VSage+R0NeW8zXcP1/iMAXAtQOz0yiklL7N cpCddjaIe5xrYAsaLSb4fVSsIhcRkD9QbEvR3PHB+uwgcSTKt80cbvpUxnfnKdXIy/oD WZ3gE0SadfVd+eBcqjXLm6M3Kpm4Cd2dGWjBscGkfzcgvBgY1pcGgKxgIhN6RAdP7Z1d 5t8g== X-Gm-Message-State: AHQUAuaagwRXFRbXS5EoGvExyO2lrrjbkFTXHaefvSS9wcRfX2yOj+Oq 8gvD0MGS1KM34BQlW01+ZwXThA== X-Received: by 2002:a2e:2d4:: with SMTP id y81-v6mr2328076lje.62.1550148593641; Thu, 14 Feb 2019 04:49:53 -0800 (PST) Received: from genomnajs.ideon.se ([85.235.10.227]) by smtp.gmail.com with ESMTPSA id r7-v6sm410853ljg.85.2019.02.14.04.49.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 14 Feb 2019 04:49:52 -0800 (PST) From: Linus Walleij To: Greg Kroah-Hartman , stable@vger.kernel.org, openwrt-devel@lists.openwrt.org Cc: "David S . Miller" , Eric Dumazet , Liping Zhang , John Youn , =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= , James Hughes , Felix Fietkau , Boris Brezillon , Richard Weinberger Subject: [PATCH 6/8 v2] ubifs: Use dirty_writeback_interval value for wbuf timer Date: Thu, 14 Feb 2019 13:49:08 +0100 Message-Id: <20190214124910.1753-7-linus.walleij@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190214124910.1753-1-linus.walleij@linaro.org> References: <20190214124910.1753-1-linus.walleij@linaro.org> MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Rafał Miłecki commit 1b7fc2c0069f3864a3dda15430b7aded31c0bfcc upstream. Right now wbuf timer has hardcoded timeouts and there is no place for manual adjustments. Some projects / cases many need that though. Few file systems allow doing that by respecting dirty_writeback_interval that can be set using sysctl (dirty_writeback_centisecs). Lowering dirty_writeback_interval could be some way of dealing with user space apps lacking proper fsyncs. This is definitely *not* a perfect solution but we don't have ideal (user space) world. There were already advanced discussions on this matter, mostly when ext4 was introduced and it wasn't behaving as ext3. Anyway, the final decision was to add some hacks to the ext4, as trying to fix whole user space or adding new API was pointless. We can't (and shouldn't?) just follow ext4. We can't e.g. sync on close as this would cause too many commits and flash wearing. On the other hand we still should allow some trade-off between -o sync and default wbuf timeout. Respecting dirty_writeback_interval should allow some sane cutomizations if used warily. Signed-off-by: Rafał Miłecki Reviewed-by: Boris Brezillon Signed-off-by: Richard Weinberger --- - This was applied upstream in v4.10 - Should be applied to stable v4.9.y --- fs/ubifs/io.c | 8 ++++---- fs/ubifs/ubifs.h | 4 ---- 2 files changed, 4 insertions(+), 8 deletions(-) -- 2.20.1 diff --git a/fs/ubifs/io.c b/fs/ubifs/io.c index 4d6ce4a2a4b6..3be28900bf37 100644 --- a/fs/ubifs/io.c +++ b/fs/ubifs/io.c @@ -452,11 +452,11 @@ static enum hrtimer_restart wbuf_timer_callback_nolock(struct hrtimer *timer) */ static void new_wbuf_timer_nolock(struct ubifs_wbuf *wbuf) { - ktime_t softlimit = ktime_set(WBUF_TIMEOUT_SOFTLIMIT, 0); - unsigned long long delta; + ktime_t softlimit = ms_to_ktime(dirty_writeback_interval * 10); + unsigned long long delta = dirty_writeback_interval; - delta = WBUF_TIMEOUT_HARDLIMIT - WBUF_TIMEOUT_SOFTLIMIT; - delta *= 1000000000ULL; + /* centi to milli, milli to nano, then 10% */ + delta *= 10ULL * NSEC_PER_MSEC / 10ULL; ubifs_assert(!hrtimer_active(&wbuf->timer)); ubifs_assert(delta <= ULONG_MAX); diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h index ade4b3137a1d..b8b18d446a49 100644 --- a/fs/ubifs/ubifs.h +++ b/fs/ubifs/ubifs.h @@ -83,10 +83,6 @@ */ #define BGT_NAME_PATTERN "ubifs_bgt%d_%d" -/* Write-buffer synchronization timeout interval in seconds */ -#define WBUF_TIMEOUT_SOFTLIMIT 3 -#define WBUF_TIMEOUT_HARDLIMIT 5 - /* Maximum possible inode number (only 32-bit inodes are supported now) */ #define MAX_INUM 0xFFFFFFFF