linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Yafang Shao <laoar.shao@gmail.com>,
	jack@suse.cz, mhocko@suse.com, hannes@cmpxchg.org,
	vdavydov.dev@gmail.com, jlayton@redhat.com, nborisov@suse.com,
	tytso@mit.edu, mawilcox@microsoft.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH] mm/page-writeback.c: fix bug caused by disable periodic writeback
Date: Tue, 10 Oct 2017 10:45:01 +0200	[thread overview]
Message-ID: <20171010084501.GC775@quack2.suse.cz> (raw)
In-Reply-To: <20171009154212.bdf3645a2dce5d540657914b@linux-foundation.org>

On Mon 09-10-17 15:42:12, Andrew Morton wrote:
> On Sat,  7 Oct 2017 06:58:04 +0800 Yafang Shao <laoar.shao@gmail.com> wrote:
> 
> > After disable periodic writeback by writing 0 to
> > dirty_writeback_centisecs, the handler wb_workfn() will not be
> > entered again until the dirty background limit reaches or
> > sync syscall is executed or no enough free memory available or
> > vmscan is triggered.
> > So the periodic writeback can't be enabled by writing a non-zero
> > value to dirty_writeback_centisecs
> > As it can be disabled by sysctl, it should be able to enable by 
> > sysctl as well.
> > 
> > ...
> >
> > --- a/mm/page-writeback.c
> > +++ b/mm/page-writeback.c
> > @@ -1972,7 +1972,13 @@ bool wb_over_bg_thresh(struct bdi_writeback *wb)
> >  int dirty_writeback_centisecs_handler(struct ctl_table *table, int write,
> >  	void __user *buffer, size_t *length, loff_t *ppos)
> >  {
> > -	proc_dointvec(table, write, buffer, length, ppos);
> > +	unsigned int old_interval = dirty_writeback_interval;
> > +	int ret;
> > +
> > +	ret = proc_dointvec(table, write, buffer, length, ppos);
> > +	if (!ret && !old_interval && dirty_writeback_interval)
> > +		wakeup_flusher_threads(0, WB_REASON_PERIODIC);
> > +
> >  	return 0;
> 
> We could do with a code comment here, explaining why this code exists.
> 
> And...  I'm not sure it works correctly?  For example, if a device
> doesn't presently have bdi_has_dirty_io() then wakeup_flusher_threads()
> will skip it and the periodic writeback still won't be started?

This works correctly. For this case __mark_inode_dirty() has:

      if (bdi_cap_writeback_dirty(wb->bdi) && wakeup_bdi)
              wb_wakeup_delayed(wb);

So periodic writeback gets automatically started once first dirty inode
appears on a bdi.

> (why does the dirty_writeback_interval==0 special case exist, btw? 
> Seems to be a strange thing to do).

I guess to prevent busylooping? But I'm not sure...
 
> (and what happens if the interval was set to 1 hour and the user
> rewrites that to 1 second?  Does that change take 1 hour to take
> effect?)

That's a good point I didn't think about. So probably we should do the
wakeup whenever dirty_writeback_interval changes. 

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

--
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>

  parent reply	other threads:[~2017-10-10  8:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-06 22:58 [PATCH] mm/page-writeback.c: fix bug caused by disable periodic writeback Yafang Shao
2017-10-09  9:56 ` Jan Kara
2017-10-09 22:42 ` Andrew Morton
2017-10-10  8:00   ` Yafang Shao
2017-10-10  8:48     ` Jan Kara
2017-10-10  9:14       ` Yafang Shao
2017-10-10  9:33         ` Jan Kara
2017-10-11  4:06           ` Yafang Shao
2017-10-10  8:45   ` Jan Kara [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-10-09 10:44 Yafang Shao
2017-10-09 11:03 ` Jan Kara
2017-10-09 11:36   ` Yafang Shao

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=20171010084501.GC775@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=hannes@cmpxchg.org \
    --cc=jlayton@redhat.com \
    --cc=laoar.shao@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mawilcox@microsoft.com \
    --cc=mhocko@suse.com \
    --cc=nborisov@suse.com \
    --cc=tytso@mit.edu \
    --cc=vdavydov.dev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).