linux-kernel - Re: regression in page writeback

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: <20090925032611.GC10487@localhost>
Date:	Fri, 25 Sep 2009 11:26:11 +0800
From:	Wu Fengguang <fengguang.wu@...el.com>
To:	Chris Mason <chris.mason@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"Li, Shaohua" <shaohua.li@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"richard@....demon.co.uk" <richard@....demon.co.uk>,
	"jens.axboe@...cle.com" <jens.axboe@...cle.com>
Cc:	Dave Chinner <david@...morbit.com>,
	"hch@...radead.org" <hch@...radead.org>
Subject: Re: regression in page writeback

On Thu, Sep 24, 2009 at 08:10:34PM +0800, Chris Mason wrote:
> On Thu, Sep 24, 2009 at 11:15:08AM +0800, Wu Fengguang wrote:
> 
> [ why do the bdi-writeback work? ]
> 
[snip]
> > > The congestion checks prevent any attempts from the filesystem to write
> > > a whole extent (or a large portion of an extent) at a time.
> > 
> > Since writepage is called one by one for each page, will its
> > interleaveness impact filesystem decisions? Ie. between these two
> > writepage sequences.
> > 
> >         A1, B1, A2, B2, A3, B3, A4, B4
> >         A1, A2, A3, A4, B1, B2, B3, B4
> > 
> > Where each An/Bn stands for one page of file A/B, n is page index.
> 
> For XFS this is the key question.  We're doing streaming writes, so the
> delayed allocation code is responsible for allocating extents, and this
> is triggered from writepage.  Your first example becomes:
> 
>          A1 [allocate extent A1-A50 ], submit A1
> 	 B1 [allocate extent B1-B50 ], submit B1 (seek)
> 	 A2, (seek back to A1's extent)
> 	 B2, (seek back to B1's extent)
> 	 ...
> 
> This is why the XFS graph for pdflush isn't a straight line.   When we
> back off file A and switch to file B, we seek between extents created by
> delalloc.

Does it mean XFS writeback is somehow serialized, so that the elevator
cannot do request merges well?  Hope that's not true..

> Thanks for spending time reading through all of this.  It's a ton of data
> and your improvements are much appreciated!

Thank you :)

Regards,
Fengguang
--
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/