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] [day] [month] [year] [list]
Message-ID: <20110108140801.GB13269@mtj.dyndns.org>
Date:	Sat, 8 Jan 2011 09:08:01 -0500
From:	Tejun Heo <tj@...nel.org>
To:	Christoph Hellwig <hch@....de>
Cc:	Ted Ts'o <tytso@....edu>, "Darrick J. Wong" <djwong@...ibm.com>,
	Jens Axboe <axboe@...nel.dk>, Neil Brown <neilb@...e.de>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	Alasdair G Kergon <agk@...hat.com>, Jan Kara <jack@...e.cz>,
	Mike Snitzer <snitzer@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-raid@...r.kernel.org, Keith Mannthey <kmannth@...ibm.com>,
	dm-devel@...hat.com, Mingming Cao <cmm@...ibm.com>,
	linux-ext4@...r.kernel.org, Ric Wheeler <rwheeler@...hat.com>,
	Josef Bacik <josef@...hat.com>
Subject: Re: Patch to issue pure flushes directly (Was: Re: [PATCH v6 0/4]
 ext4: Coordinate data-only flush requests sent) by fsync

Hello,

On Sat, Jan 08, 2011 at 08:45:24AM +0100, Christoph Hellwig wrote:
> On Fri, Jan 07, 2011 at 06:54:49PM -0500, Ted Ts'o wrote:
> > This patch seemed like a good idea to me; I just checked linux-next,
> > and looks like nothing like this is planned to be merged.  Just
> > thought I would send a prod-o-gram to see what the current thinking
> > was around adding something like this.
> 
> I haven't really gotten any feedback on the patch, so it fell on the
> floor for a while.  I've managed to get some big system resources to
> test the impact of it, and once I've got numbers I'll resend it as
> separate patches for scsi and the block layer.

But would it actually make any difference?  It's not like the usual
completion path in the optimized case is much longer.  It will set all
the skip bits, try to determine the next step which is completion and
then complete the flush request.  It'll sure occupy the CPU for a
little bit longer but I don't think it will be anything measureable.
Is there a workload that this can actually help?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ