All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "Richard Weinberger" <richard@nod.at>,
	"Artem Bityutskiy" <dedekind1@gmail.com>,
	"Adrian Hunter" <adrian.hunter@intel.com>,
	"Rafał Miłecki" <rafal@milecki.pl>,
	linux-mtd@lists.infradead.org
Subject: Re: [PATCH 2/2] ubifs: use dirty_writeback_interval value for wbuf timer
Date: Wed, 14 Sep 2016 17:48:58 +0200	[thread overview]
Message-ID: <20160914174858.2bc8ff2e@bbrezillon> (raw)
In-Reply-To: <20160914102435.22312-3-zajec5@gmail.com>

On Wed, 14 Sep 2016 12:24:35 +0200
Rafał Miłecki <zajec5@gmail.com> wrote:

> From: Rafał Miłecki <rafal@milecki.pl>
> 
> 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 <rafal@milecki.pl>
> ---
>  fs/ubifs/io.c    | 7 ++-----
>  fs/ubifs/ubifs.h | 4 ----
>  2 files changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/fs/ubifs/io.c b/fs/ubifs/io.c
> index 4d6ce4a..aced6ee 100644
> --- a/fs/ubifs/io.c
> +++ b/fs/ubifs/io.c
> @@ -452,11 +452,8 @@ 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;
> -
> -	delta = WBUF_TIMEOUT_HARDLIMIT - WBUF_TIMEOUT_SOFTLIMIT;
> -	delta *= 1000000000ULL;
> +	ktime_t softlimit = ms_to_ktime(dirty_writeback_interval * 10);
> +	unsigned long long delta = dirty_writeback_interval; /* 10% delta */

dirty_writeback_interval is expressed in centiseconds, and delta is in
nanoseconds.

I think you miss

	delta *= 10000000ULL;

>  
>  	ubifs_assert(!hrtimer_active(&wbuf->timer));
>  	ubifs_assert(delta <= ULONG_MAX);
> diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
> index 11bc8fa..26e6340 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
>  

  reply	other threads:[~2016-09-14 15:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-14 10:24 [PATCH 1/2] ubifs: drop softlimit and delta fields from struct ubifs_wbuf Rafał Miłecki
2016-09-14 10:24 ` [PATCH 2/2] ubifs: use dirty_writeback_interval value for wbuf timer Rafał Miłecki
2016-09-14 15:48   ` Boris Brezillon [this message]
2016-09-14 15:24 ` [PATCH 1/2] ubifs: drop softlimit and delta fields from struct ubifs_wbuf Boris Brezillon
2016-09-14 15:28   ` Boris Brezillon
2016-09-14 15:40 ` Boris Brezillon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160914174858.2bc8ff2e@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=adrian.hunter@intel.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=rafal@milecki.pl \
    --cc=richard@nod.at \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.