linux-kernel - Re: [xfs-masters] linux-next: manual merge of the xfs tree with Linus' tree

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]

Date:	Mon, 28 Mar 2011 13:00:40 +0200
From:	Christoph Hellwig <hch@....de>
To:	Jens Axboe <jaxboe@...ionio.com>
Cc:	Christoph Hellwig <hch@....de>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	David Chinner <david@...morbit.com>,
	"xfs-masters@....sgi.com" <xfs-masters@....sgi.com>,
	"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [xfs-masters] linux-next: manual merge of the xfs tree with
	Linus' tree

On Mon, Mar 28, 2011 at 12:58:09PM +0200, Jens Axboe wrote:
> Yes, in fact all of the blk_flush_plug() calls in XFS can just go away
> now. I tried to keep them for clarity, but they are primarily there
> since XFS was the first conversion/testing I did back when it was hacked
> up.

It seems like the xfsbufd can go away, too indeed.  If we have more
work to do it makes sense not to plug, and if we don't have more
work we are going to sleep.

I think the one in xfs_flush_buftarg actually does make sense to
keep - we really want to flush out all pending I/O before waiting for
it.  But I guess for both of these we just want to add an explicit
plug/unlug pair to optimize the I/O dispatch.

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