linux-ext4 - Re: [PATCH 2/8 v3] 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]

Date:	Thu, 8 Nov 2012 18:21:23 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Zheng Liu <gnehzuil.liu@...il.com>
Cc:	linux-ext4@...r.kernel.org, jeff.liu@...cle.com, hughd@...gle.com,
	xiaoqiangnk@...il.com, achender@...ux.vnet.ibm.com,
	lczerner@...hat.com, Zheng Liu <wenqing.lz@...bao.com>
Subject: Re: [PATCH 2/8 v3] ext4: add operations on extent status tree

On Fri, Oct 26, 2012 at 09:23: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

Hi Zheng,

I can fix this up, before I finalize your commit, but I just want to
check.  I believe this comment is out of date --- we are now using a
r/w spinlock, i_es_lock, yes?  Since we never hold the spinlock for
very long, I would be surprised if this is going to be a scalability
bottleneck (too bad Eric doesn't have access to the big SMP machine
that he used to use to help us do our scalability testing, so we could
check to be sure).

    			       	     	      - 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