From patchwork Thu Feb 14 13:24:01 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 158389 Delivered-To: patch@linaro.org Received: by 2002:a02:48:0:0:0:0:0 with SMTP id 69csp1367029jaa; Thu, 14 Feb 2019 05:24:49 -0800 (PST) X-Google-Smtp-Source: AHgI3Ias5MFs4eTlnni7rsXpWdTgTEua/JkjYf//qyejjx61MWSFrUviPvfLznQTmTKU5qLLUa4K X-Received: by 2002:a17:902:20e9:: with SMTP id v38mr4046858plg.250.1550150689883; Thu, 14 Feb 2019 05:24:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550150689; cv=none; d=google.com; s=arc-20160816; b=xXvo3gC+rwynp4c/t4lpRN+3/JK7Ffkqjul/Y11igWGqujo+Kkkc9AhBstwz49CDIL 4sHcfvQldhvUIfvamZI1sLxSsavuQbXrTsR5Tw4YS1R2bSw+9tCmLMcy9lfMQD+NZEch FIpo08dW+t21XMf2nn0JLVrjnragOHHKXWpGey+qdBb1yYl9yJnahc7biVZIQlbk9ADs /UHztbsUwpMaagx2F+1Ow6Q4EoIjkd4KVIJF5MV+iGwlQ4XHLbB8BramfZZ0o5Wnm8Lq mDjxjL8pM4SD01BUjk+fOzl0o3VG1tk0LT6IJfXs9dw7HksZNrhTS4l66mJgTHYET2IS kVhA== 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=JnOpFuWei3nzemVBDjN3MgW2JlSWE/slWX5N0EfPGcw=; b=pvp06QgYFKYWl6OAYJyAqoNi7GFhIHnvU4vDrIxNckgtDP9wy7EB3vApizfEBEBL+u +3Jcn+bt4KNGplgIUu3v2vrD8Zg4Vw9+h9khk65VIx1VwimIlRADLCDv/TWUUhGzmB3d T+rjLxUTcUWdCYYjSuOkqJI/n1ZiSQJEVgFlosAIvFQbIwGjQdghoxuM8+oMCtFqXrZY dTQ0F32vOgb3uenNwDcgmaaywKoQHl3XQEbx4604LNufmbP6gsH133sHtPaj8vsJG3gC FUdPeqoRXSY8Jkwe9O/OYY9CinS7mZ9onoixeL28KZ7ndZ4TJmYmQF5YPteu47uJt7yc 3Mcg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=ah27IPWr; 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 36si2748782plc.250.2019.02.14.05.24.49; Thu, 14 Feb 2019 05:24:49 -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=ah27IPWr; 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 S1732439AbfBNNYt (ORCPT + 15 others); Thu, 14 Feb 2019 08:24:49 -0500 Received: from mail-lj1-f195.google.com ([209.85.208.195]:39748 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727469AbfBNNYs (ORCPT ); Thu, 14 Feb 2019 08:24:48 -0500 Received: by mail-lj1-f195.google.com with SMTP id g80so5211482ljg.6 for ; Thu, 14 Feb 2019 05:24:47 -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=JnOpFuWei3nzemVBDjN3MgW2JlSWE/slWX5N0EfPGcw=; b=ah27IPWrk7XBW/zEI7KK3m0tEyjw8zSRQHo7V69O6Tg56+M5bkDfCpsIvHVYnrZzIU stp23jXq7T1r5bClO9Tdx70Y+9AM0SCIEw3Gv2+tBNnLqH2pklXD9P7/F8pqGEwyqRjo 2ENuJaRWZvDFKVdZfWUNZrhySxLTSWrgQutcaYe6gwZZA5PQKklzj6TLPV+NRRBhj5S1 WfoRS27VLMUf8I3olE8S6/GDkJAJAVWeJOFLxaVBzQuCwkT4m/4U3bQAaRwlnBQ3GB+m 4299VEjI67qlZBkwK0ZIKdLUER/00f22+VCerktpirowC0CyS1JRrJt1nrgwWwFOZ75b dUlQ== 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=JnOpFuWei3nzemVBDjN3MgW2JlSWE/slWX5N0EfPGcw=; b=jleSTBrcm5+ZhgSKtFatp9wfjHcNtqLkVLGaa890hkIMDsY2fJi8/PdfQKKUA6ClND O7d3w77CLqHWgmuWJxq3w4Cg4li1R4yQ/bMoxhOYlVm0JlX96weDCG2Y4KXVkHfeaNy6 RT6yU5dpJoO0+Mb1dMNWmfuNdqTQaTjzc0Yi8xzssoL/uypcByRwAlZIWlluxcmBoQcj mAnLkPlWcg7lxa+dgnYb3DSJ1P59EX2GtCJHjAsozpNqhCNuSPmFMRA1E132D+g2WU7H R8Kqsge9UgYvGXInXDdLjb8X7U+eBWVHlworqgn5aOS5bP+RsYoQgYS+ZzDgJcWgGcun yrlQ== X-Gm-Message-State: AHQUAub1KGLnk0rTHn9Gj1SHsnXd80uvtDCZ3+HLj3hVmGBi5FuQehdb gkBi4BnOLkBw6A2TyOrmLfPcEAXLWrI= X-Received: by 2002:a2e:587:: with SMTP id 129mr2367651ljf.25.1550150687070; Thu, 14 Feb 2019 05:24:47 -0800 (PST) Received: from genomnajs.ideon.se ([85.235.10.227]) by smtp.gmail.com with ESMTPSA id k13-v6sm427752ljg.84.2019.02.14.05.24.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 14 Feb 2019 05:24:45 -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 , Linus Walleij Subject: [PATCH 6/8 v3] ubifs: Use dirty_writeback_interval value for wbuf timer Date: Thu, 14 Feb 2019 14:24:01 +0100 Message-Id: <20190214132403.10687-7-linus.walleij@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190214132403.10687-1-linus.walleij@linaro.org> References: <20190214132403.10687-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 Signed-off-by: Linus Walleij --- - 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