linux-ext4 - Re: [PATCH 2/4] jbd2/log_wait_for_space: drop checkpoint mutex when waiting

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: <51B72403.1070702@windriver.com>
Date:	Tue, 11 Jun 2013 09:20:03 -0400
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	"Theodore Ts'o" <tytso@....edu>
CC:	<linux-ext4@...r.kernel.org>, <linux-rt-users@...r.kernel.org>
Subject: Re: [PATCH 2/4] jbd2/log_wait_for_space: drop checkpoint mutex when
 waiting

On 13-06-11 09:03 AM, Theodore Ts'o wrote:
> On Mon, Jun 10, 2013 at 11:20:50PM -0400, Paul Gortmaker wrote:
>>
>> Absolutely; will do that tomorrow and re-test on 3.10-rc5.
> 
> Thanks!!  And by the way, I did look at patches #3 and #4 in your
> series, and they looked fine.  If you're going to be resending a new
> patch series shortly, I won't bother grabbing them now and wait for
> your new series, but if you won't have time to complete your testing,
> the patches are independent and easy to validate by inspection, so I
> could also just pull them into the ext4 tree earlier.

I'll definitely respin them and retest today, so no need for you to
bother manually dealing with the two trivial ones independently.

> 
> Cheers, and good luck figuring out the RT problem.

Thanks!

> 
> 	    	      	       	       - Ted
> 
> P.S.  About the bit spinlock patches in the RT Tree...  Something that
> might be interesting to do if you have the time is to measure the
> performance differential on non-realtime kernels to replace the bit
> spinlocks with normal spinlocks.  The two main issues with it I can
> forsee is the potential increased memory overhead (since a system can
> have a huge number of bh's), but if this were offset with performance
> gains (and we can confirm no performance losses moving away from bit
> spinlocks), I'm not wedded to keeping them.  Other folks in the

Good to know.  I'll keep it in mind to try some performance tests on
a jbd[2] converted non-RT kernel when I have time.  I expect with the
advent of hlist_bl_head we'll see more and more users of bit_spin,
but at least those ones can be "fixed" all in one place for RT.

Paul.
--

> fsdevel community may push back on adding spinlocks to the bh that
> many other file systems would have no use for, and that may very well
> be a concern, but if we understand what the tradeoffs are, both pro
> and con, it's something we can have a reasonable discussion about.
> 
--
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