linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
To: Yong Wang <yong.y.wang@linux.intel.com>
Cc: "Wu, Xia" <xia.wu@intel.com>, Christoph Hellwig <hch@lst.de>,
	Jens Axboe <jaxboe@fusionio.com>,
	"Wu, Fengguang" <fengguang.wu@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH] bdi: use deferable timer for sync_supers task
Date: Fri, 08 Oct 2010 16:59:21 +0300	[thread overview]
Message-ID: <1286546361.2095.92.camel@localhost> (raw)
In-Reply-To: <20101008102709.GA12682@ywang-moblin2.bj.intel.com>

On Fri, 2010-10-08 at 18:27 +0800, Yong Wang wrote:
> On Fri, Oct 08, 2010 at 01:28:07PM +0300, Artem Bityutskiy wrote:
> > On Fri, 2010-10-08 at 18:27 +0800, Wu, Xia wrote:
> > > > However, when the next wake-up interrupt happens is not defined. It can
> > > > happen 1ms after, or 1 minute after, or 1 hour after. What Christoph
> > > > says is that there should be some guarantee that sb writeout starts,
> > > > say, within 5 to 10 seconds interval. Deferrable timers do not guarantee
> > > > this. But take a look at the range hrtimers - they do exactly this.
> > > 
> > > If the system is in sleep state, is there any data which should be written?
> > 
> > May be yes, may be no.
> > 
> 
> Thanks for the quick response, Artem. May I know what might need to be
> written out when system is really idle?

I do not understand the question. There is dirty data, and it should be
flushed within some time interval.

Anyway, to make the long story short, I made an attempt to optimize this
and stop arming the timer when we have no dirty data. But my solution
was not accepted and Al asked me to just get rid of this timer and whole
sync_supers(). He said this should be pushed down to individual FSes. I
guess the idea is that

1) some FSes actually abuse sb synching, e.g., JFFS2.
2) other FSes can eventually optimize things for themselves.

But I did not find time to do this so far.

-- 
Best Regards,
Artem Bityutskiy (D?N?N?N?D 1/4  D?D,N?N?N?DoD,D1)

--
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:[~2010-10-08 14:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-08  8:35 [PATCH] bdi: use deferable timer for sync_supers task Yong Wang
2010-10-08  9:25 ` Christoph Hellwig
2010-10-08 10:02   ` Artem Bityutskiy
2010-10-08 10:04   ` Wu, Xia
2010-10-08 10:09     ` Artem Bityutskiy
2010-10-08 10:27       ` Wu, Xia
2010-10-08 10:28         ` Artem Bityutskiy
2010-10-08 10:27           ` Yong Wang
2010-10-08 13:57             ` Wu Fengguang
2010-10-08 14:42               ` Wu Fengguang
2010-10-08 13:59             ` Artem Bityutskiy [this message]

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=1286546361.2095.92.camel@localhost \
    --to=artem.bityutskiy@nokia.com \
    --cc=fengguang.wu@intel.com \
    --cc=hch@lst.de \
    --cc=jaxboe@fusionio.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=xia.wu@intel.com \
    --cc=yong.y.wang@linux.intel.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).