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]

Date:	Fri, 21 Dec 2012 12:46:02 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Jan Kara <jack@...e.cz>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH RFC] jbd: don't wake kjournald unnecessarily

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?

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.  

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.  :-)

						- 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