lkml.org 
[lkml]   [2013]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: jbd2: don't wake kjournald unnecessarily
On Wed 23-01-13 09:20:38, Eric Sandeen wrote:
> On 1/23/13 3:44 AM, Jan Kara wrote:
> > On Tue 22-01-13 19:37:46, Eric Sandeen wrote:
> >> On 1/22/13 5:50 PM, Jan Kara wrote:
> >>> On Mon 21-01-13 18:11:30, Ted Tso wrote:
> >>>> On Tue, Jan 22, 2013 at 12:04:32AM +0100, Sedat Dilek wrote:
> >>>>>
> >>>>> Beyond the FUSE/LOOP fun, will you apply this patch to your linux-next GIT tree?
> >>>>>
> >>>>> Feel free to add...
> >>>>>
> >>>>> Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
> >>>>>
> >>>>> A similiar patch for JBD went through your tree into mainline (see [1] and [2]).
> >>>>
> >>>> I'm not at all convinced that this patch has anything to do with your
> >>>> problem. I don't see how it could affect things, and I believe you
> >>>> mentioned that you saw the problem even with this patch applied? (I'm
> >>>> not sure; some of your messages which you sent were hard to
> >>>> understand, and you mentioned something about trying to send messages
> >>>> when low on sleep :-).
> >>>>
> >>>> In any case, the reason why I haven't pulled this patch into the ext4
> >>>> tree is because I was waiting for Eric and some of the performance
> >>>> team folks at Red Hat to supply some additional information about why
> >>>> this commit was making a difference in performance for a particular
> >>>> proprietary, closed source benchmark.
> >>> Just a small correction - it was aim7 AFAIK which isn't closed source
> >>> (anymore). You can download it from SourceForge
> >>> (http://sourceforge.net/projects/aimbench/files/aim-suite7/Initial%20release/).
> >>> Now I have some reservations about what the benchmark does but historically
> >>> it has found quite a few issues for us as well.
> >>>
> >>>> I'm very suspicious about applying patches under the "cargo cult"
> >>>> school of programming. ("We don't understand why it makes a
> >>>> difference, but it seems to be good, so bombs away!" :-)
> >>> Well, neither am I ;) But it is obvious the patch speeds up
> >>> log_start_commit() by 'a bit' (taking spinlock, disabling irqs, ...). And
> >>> apparently 'a bit' is noticeable for particular workload on a particular
> >>> machine - commit statistics Eric provided showed that clearly. I'd still be
> >>> happier if Eric also told us how much log_start_commit() calls there were
> >>> so that one could verify that 'a bit' could indeed multiply to a measurable
> >>> difference. But given how simple the patch is, I gave away after a while
> >>> and just merged it...
> >>
> >> I am still trying to get our perf guys to collect that data, FWIW...
> >> I will send it when I get it. I bugged them again today. :)
> >>
> >> (Just to be sure: I was going to measure the wakeups the old way, and the
> >> avoided wakeups with the new change; sound ok?)
> > Yes, that would be what I'm interested in.
>
> Holy cow, this is much more than I expected, but here's what they report:
>
> old JBD: AIM7 jobs/min 97624.39; got 78193 jbd wakeups
> new JBD: AIM7 jobs/min 85929.43; got 6306999 jbd wakeups, 6264684 extra wakeups
Yeah, that's a lot. My guess would be *a lot* of processes are hanging in
start_this_handle() and waiting for transaction commit. Each of them calls
__log_start_commit() and things add up. Thanks for getting these numbers.

Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR


\
 
 \ /
  Last update: 2013-01-23 21:02    [W:0.178 / U:2.624 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site