linux-kernel - Re: [PATCH] bdi: use deferable timer for sync

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1286546361.2095.92.camel@localhost>
Date:	Fri, 08 Oct 2010 16:59:21 +0300
From:	Artem Bityutskiy <Artem.Bityutskiy@...ia.com>
To:	Yong Wang <yong.y.wang@...ux.intel.com>
Cc:	"Wu, Xia" <xia.wu@...el.com>, Christoph Hellwig <hch@....de>,
	Jens Axboe <jaxboe@...ionio.com>,
	"Wu, Fengguang" <fengguang.wu@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH] bdi: use deferable timer for sync_supers task

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 (Артём Битюцкий)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/