All of lore.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Neil Brown <neilb@suse.de>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"riel@redhat.com" <riel@redhat.com>,
	"david@fromorbit.com" <david@fromorbit.com>,
	"hch@lst.de" <hch@lst.de>, "axboe@kernel.dk" <axboe@kernel.dk>
Subject: Re: [PATCH] writeback: remove the internal 5% low bound on dirty_ratio
Date: Mon, 23 Aug 2010 16:30:40 +1000	[thread overview]
Message-ID: <201008231630.40892.kernel@kolivas.org> (raw)
In-Reply-To: <20100823062359.GA19586@localhost>

On Mon, 23 Aug 2010 04:23:59 pm Wu Fengguang wrote:
> On Mon, Aug 23, 2010 at 12:42:48PM +0800, Neil Brown wrote:
> > On Fri, 20 Aug 2010 15:50:54 +1000
> >
> > Con Kolivas <kernel@kolivas.org> wrote:
> > > On Fri, 20 Aug 2010 02:13:25 pm KOSAKI Motohiro wrote:
> > > > > The dirty_ratio was silently limited to >= 5%. This is not a user
> > > > > expected behavior. Let's rip it.
> > > > >
> > > > > It's not likely the user space will depend on the old behavior.
> > > > > So the risk of breaking user space is very low.
> > > > >
> > > > > CC: Jan Kara <jack@suse.cz>
> > > > > CC: Neil Brown <neilb@suse.de>
> > > > > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> > > >
> > > > Thank you.
> > > > 	Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> > >
> > > I have tried to do this in the past, and setting this value to 0 on
> > > some machines caused the machine to come to a complete standstill with
> > > small writes to disk. It seemed there was some kind of "minimum" amount
> > > of data required by the VM before anything would make it to the disk
> > > and I never quite found out where that blockade occurred. This was some
> > > time ago (3 years ago) so I'm not sure if the problem has since been
> > > fixed in the VM since then. I suggest you do some testing with this
> > > value set to zero before approving this change.
>
> You are right, vm.dirty_ratio=0 will block applications for ever..

Indeed. And while you shouldn't set the lower limit to zero to avoid this 
problem, it doesn't answer _why_ this happens. What is this "minimum write" 
that blocks everything, will 1% be enough, and is it hiding another real bug 
somewhere in the VM?

Regards,
Con
--
-ck

WARNING: multiple messages have this Message-ID (diff)
From: Con Kolivas <kernel@kolivas.org>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Neil Brown <neilb@suse.de>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"riel@redhat.com" <riel@redhat.com>,
	"david@fromorbit.com" <david@fromorbit.com>,
	"hch@lst.de" <hch@lst.de>, "axboe@kernel.dk" <axboe@kernel.dk>
Subject: Re: [PATCH] writeback: remove the internal 5% low bound on dirty_ratio
Date: Mon, 23 Aug 2010 16:30:40 +1000	[thread overview]
Message-ID: <201008231630.40892.kernel@kolivas.org> (raw)
In-Reply-To: <20100823062359.GA19586@localhost>

On Mon, 23 Aug 2010 04:23:59 pm Wu Fengguang wrote:
> On Mon, Aug 23, 2010 at 12:42:48PM +0800, Neil Brown wrote:
> > On Fri, 20 Aug 2010 15:50:54 +1000
> >
> > Con Kolivas <kernel@kolivas.org> wrote:
> > > On Fri, 20 Aug 2010 02:13:25 pm KOSAKI Motohiro wrote:
> > > > > The dirty_ratio was silently limited to >= 5%. This is not a user
> > > > > expected behavior. Let's rip it.
> > > > >
> > > > > It's not likely the user space will depend on the old behavior.
> > > > > So the risk of breaking user space is very low.
> > > > >
> > > > > CC: Jan Kara <jack@suse.cz>
> > > > > CC: Neil Brown <neilb@suse.de>
> > > > > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> > > >
> > > > Thank you.
> > > > 	Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> > >
> > > I have tried to do this in the past, and setting this value to 0 on
> > > some machines caused the machine to come to a complete standstill with
> > > small writes to disk. It seemed there was some kind of "minimum" amount
> > > of data required by the VM before anything would make it to the disk
> > > and I never quite found out where that blockade occurred. This was some
> > > time ago (3 years ago) so I'm not sure if the problem has since been
> > > fixed in the VM since then. I suggest you do some testing with this
> > > value set to zero before approving this change.
>
> You are right, vm.dirty_ratio=0 will block applications for ever..

Indeed. And while you shouldn't set the lower limit to zero to avoid this 
problem, it doesn't answer _why_ this happens. What is this "minimum write" 
that blocks everything, will 1% be enough, and is it hiding another real bug 
somewhere in the VM?

Regards,
Con
--
-ck

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-08-23  6:31 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-20  3:25 [PATCH] writeback: remove the internal 5% low bound on dirty_ratio Wu Fengguang
2010-08-20  3:25 ` Wu Fengguang
2010-08-20  3:46 ` Rik van Riel
2010-08-20  3:46   ` Rik van Riel
2010-08-20  4:13 ` KOSAKI Motohiro
2010-08-20  4:13   ` KOSAKI Motohiro
2010-08-20  5:50   ` Con Kolivas
2010-08-20  5:50     ` Con Kolivas
2010-08-20  5:56     ` Wu Fengguang
2010-08-20  5:56       ` Wu Fengguang
2010-08-23  4:42     ` Neil Brown
2010-08-23  4:42       ` Neil Brown
2010-08-23  6:23       ` Wu Fengguang
2010-08-23  6:23         ` Wu Fengguang
2010-08-23  6:30         ` Con Kolivas [this message]
2010-08-23  6:30           ` Con Kolivas
2010-08-23  7:15           ` Wu Fengguang
2010-08-23  7:15             ` Wu Fengguang
2010-08-24  0:00         ` KOSAKI Motohiro
2010-08-24  0:00           ` KOSAKI Motohiro
     [not found] ` <201008241620.54048.kernel@kolivas.org>
     [not found]   ` <20100824071440.GA14598@localhost>
     [not found]     ` <201008251840.00532.kernel@kolivas.org>
2010-08-26  1:29       ` Wu Fengguang
2010-08-26  1:29         ` Wu Fengguang
2010-08-26  1:36         ` Neil Brown
2010-08-26  1:36           ` Neil Brown
2010-08-26  4:22           ` KOSAKI Motohiro
2010-08-26  4:22             ` KOSAKI Motohiro
2010-08-27 10:36 Wu Fengguang
2010-08-27 10:36 ` Wu Fengguang
2010-08-27 10:39 ` Peter Zijlstra
2010-08-27 10:39   ` Peter Zijlstra
2010-08-27 10:39   ` Peter Zijlstra
2010-08-27 13:47 ` Rik van Riel
2010-08-27 13:47   ` Rik van Riel

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=201008231630.40892.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=david@fromorbit.com \
    --cc=fengguang.wu@intel.com \
    --cc=hch@lst.de \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=neilb@suse.de \
    --cc=riel@redhat.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.