linux-ext4 - Re: [RFC][PATCH 2/8 v2] ext4: add operations on extent status 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]

Message-ID: <20120919183452.GB28470@thunk.org>
Date:	Wed, 19 Sep 2012 14:34:52 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Zheng Liu <gnehzuil.liu@...il.com>
Cc:	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	Lukas Czerner <lczerner@...hat.com>,
	Yongqiang Yang <xiaoqiangnk@...il.com>,
	Allison Henderson <achender@...ux.vnet.ibm.com>,
	Zheng Liu <wenqing.lz@...bao.com>
Subject: Re: [RFC][PATCH 2/8 v2] ext4: add operations on extent status tree

On Wed, Aug 22, 2012 at 02:05:39PM +0800, Zheng Liu wrote:
> + * 3. performance analysis
> + *   --	overhead
> + *	1. Apart from operations on a delayed extent tree, we need to
> + *	down_write(inode->i_data_sem) in delayed write path to maintain delayed
> + *	extent tree, this can have impact on parallel read-write and write-write

I'm working on going through this patch set now, and I'm not sure this
is worth holding back on this patch series, but I am really concerned
about the performance impact of this....  it would definitely show up
on some of the scalability testing that Eric Whitney had been doing,
for example.

Given that operations on the delayed extent tree should be fast,
instead of using a mutex, any reason why we can't just add a new
spinlock (I'm not even sure we need a rw_spinlock here) to the
ext4_inode_info structure and use that to serialize operations on the
delayed extent tree?

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