linux-ext4 - Re: [PATCH RFC] jbd: don't wake kjournald unnecessarily

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: <50EC713D.6030800@redhat.com>
Date:	Tue, 08 Jan 2013 13:19:25 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	"Theodore Ts'o" <tytso@....edu>
CC:	Jan Kara <jack@...e.cz>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH RFC] jbd: don't wake kjournald unnecessarily

On 12/21/12 11:46 AM, Theodore Ts'o wrote:
> On Fri, Dec 21, 2012 at 11:01:58AM -0600, Eric Sandeen wrote:
>>> I'm also really puzzled about how Eric's patch makes a 10% different
>>> on the AIM7 benchmark; as you've pointed out, that will just cause an
>>> extra wakeup of the jbd/jbd2 thread, which should then quickly check
>>> and decide to go back to sleep.
>>
>> Ted, just to double check - is that some wondering aloud, or a NAK
>> of the original patch? :)
> 
> I'm still thinking....  Things that I don't understand worry me, since
> there's a possibility there's more going on than we think.
> 
> Did you have a chance to have your perf people enable the the
> jbd2_run_stats tracepoint, to see how the stats change with and
> without the patch?

Getting back to this; grabbing this over a whole AIM7 run would 
be huge.  I wonder if a few snapshots will be illustrative.
We can try.

> It would be interesting to see how the stats change --- in particular,
> whether the number of blocks logged per transaction is changing,
> and/or the number of blocks per transaction is changing.  It would
> also be interesting to insert a tracepoint in kjournald so we can
> track the number of times when kjournald is waking, but ends up *not*
> triggering a commit due to the commit timeout firing or
> j_commit_sequence != j_commit_request.  

Ok, I think I can do that w/ systemtap.

> I'll probably take the patch on the grounds that it's obvious, but if
> you could get your perf folks to run the experiment, I'd really
> appreciate it, just so we can understand what might be going on.
> Perhaps there's an opportunity for further optimizations, or we'll
> find that something unexpected that is evidence of a bug.  (Or maybe
> it's just a bug in our understanding, but that's also good to get
> fixed.  :-)

I'll see what I can do.

-Eric


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