linux-ext4 - [Bug 71641] Unreasonable performance degradation in ext4 with full data journaling

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: <bug-71641-13602-QpiNRvZo60@https.bugzilla.kernel.org/>
Date:	Fri, 28 Mar 2014 10:23:52 +0000
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 71641] Unreasonable performance degradation in ext4 with full
 data journaling

https://bugzilla.kernel.org/show_bug.cgi?id=71641

--- Comment #9 from Chia-Hung Chang <fredchang.tc@...il.com> ---
(In reply to Theodore Tso from comment #8)
> it's clear this isn't going to get performance up to 1.1 GB/s, but I'm
> curious how much setting JBD2_NR_BATCH changes things at 512 and 1024 and
> possibly even 2048.   Once it no longer maters a difference, if you could do
> another blktrace, and also gather lock_stat information, that would be
> useful.
> 
> To gather lock_stat information, enable CONFIG_LOCK_STAT, and then "echo 0 
> > /proc/lock_stat" before you start the workload, and then capture the
> output of /proc/lock_stat after you finish running your workload/benchmark.
> 
> If you also regather numbers with lock_stat enabled on a stock 3.11 kernel
> (and also get a /proc/lock_stat report from a stock 3.11 kernel, with and
> without data=journal), that would be useful.
> 
> If it turns out that there is some lock contention going on with some of the
> jbd2 spinlocks, there are some patches queued for 3.15 that I may have to
> ask you to try (which will mean going to something like 3.14-rc7 plus some
> additional patches from the ext4 git tree).
> 
> Thanks for your benchmarking!

Thanks for your advice.
With the same environment setting and 'dd' command,
The benchmarks of JBD2_NR_batch with data=journal are showed as following,

JBD2_NR_batch =64   ->386 MB/s

JBD2_NR_batch =254  ->400MB/s

JBD2_NR_batch =512  ->407MB/s

JBD2_NR_batch =1024 with  CONFIG_LOCK_STAT enable ->304MB/s

JBD2_NR_batch =2048 ->440MB/s

---------------------------
/proc/lock_stat report with data=journal

data collected at the end of "dd"
https://dl.dropboxusercontent.com/u/32959539/lock_stat_result

data collected in the middle of "dd" execution
https://dl.dropboxusercontent.com/u/32959539/lock_stat_result2

/proc/lock_stat report with data=ordered
https://dl.dropboxusercontent.com/u/32959539/lock_stat_ordered

------------------------------
blktrace of JBD2_NR_batch =2048 with data=journal
https://dl.dropboxusercontent.com/u/32959539/JBD2_NR_batch_2048.7z


Please tell me if you need further information.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
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