mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeff Moyer <jmoyer@redhat.com>
To: Corrado Zoccolo <czoccolo@gmail.com>, axboe@kernel.dk
Cc: Linux-Kernel <linux-kernel@vger.kernel.org>,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH 0/2] cfq-iosched: fixing RQ_NOIDLE handling.
Date: Tue, 13 Jul 2010 15:38:11 -0400	[thread overview]
Message-ID: <x49eif7p3z0.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <AANLkTilgHqtb1FbgK-d1vW6MyIyOT6MtpCcMmQcGlc7t@mail.gmail.com> (Corrado Zoccolo's message of "Fri, 9 Jul 2010 12:33:36 +0200")

Corrado Zoccolo <czoccolo@gmail.com> writes:

> Can you test the attached patch, where I also added your changes to
> make jbd(2) to perform sync writes?

I got new storage, so I have new numbers.  I only re-ran deadline and
vanilla cfq for the fs_mark only test.  The average of 10 runs comes out
like so:

deadline:    571.98
vanilla cfq: 107.42
patched cfq: 460.9

Mixed workload results with your suggested patch:

fs_mark: 15.65 files/sec
fio: 132.5 MB/s

So, again, not looking great for the mixed workload, but the patch
does improve the fs_mark only case.  Looking at the blktrace data shows
that the jbd2 thread preempts the fs_mark thread at all the right
times.  The only thing holding throughput back is the whole notion that
we need to only dispatch from one queue (even though the storage is
capable of serving both the reads and writes simultaneously).

I added in the patch that allows the simultaneous dispatch of both reads
and writes, and here are the results from that run:

fs_mark: 15.975 files/sec
fio: 132.4 MB/s

So, it looks like that didn't help.  The reason this patch doesn't come
close to the yield patch in the mixed workload is because the yield
patch set allows the fs_mark process to continue to issue I/O.  With
your patch, the fs_mark process does 64KB of I/O, the jbd2 thread does
the journal commit, and then the fio process runs again.  Given that the
fs_mark process typically only uses a small fraction of its time slice,
you end up with an unfair balance.

Now, we still have to decide whether that's a problem that needs
solving.  I tried to gather data from the field, but I've been unable to
conclusively say whether an application issues this sort of dependent
I/O.

As such, I am happy with this patch.  If we see that we need something
like the blk_yield approach, then I'm happy to resurrect that work.

Jens, do you find that an agreeable solution?  If so, you can add my
signed-off-by and tested-by to the patch that Corrado posted.

Cheers,
Jeff

  parent reply	other threads:[~2010-07-13 19:38 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-07 15:22 Corrado Zoccolo
2010-07-07 15:56 ` Corrado Zoccolo
2010-07-07 17:03 ` Jeff Moyer
2010-07-07 17:39   ` Corrado Zoccolo
2010-07-07 20:06     ` Jeff Moyer
2010-07-08 14:38       ` Corrado Zoccolo
2010-07-09 10:33       ` Corrado Zoccolo
2010-07-09 13:23         ` Vivek Goyal
2010-07-09 14:07         ` Jeff Moyer
2010-07-09 19:45           ` Corrado Zoccolo
2010-07-09 20:48             ` Jeff Moyer
2010-07-13 19:38         ` Jeff Moyer [this message]
2010-07-13 19:56           ` Vivek Goyal
2010-07-13 20:30             ` Jeff Moyer
2010-07-13 20:42               ` Vivek Goyal
2010-07-19 16:08                 ` Jeff Moyer
2010-07-19 20:31                   ` Vivek Goyal
2010-07-20 14:02                     ` Jeff Moyer
2010-07-20 14:11                   ` Christoph Hellwig
2010-07-20 14:26                     ` Vivek Goyal
2010-07-20 19:10                       ` Corrado Zoccolo
2010-07-20 19:32                         ` Vivek Goyal
2010-07-13 21:00               ` Jeff Moyer
2010-07-07 17:50   ` Vivek Goyal
2010-07-08 14:35   ` Vivek Goyal
2010-07-08 14:38     ` Jeff Moyer
2010-07-08 14:45     ` Corrado Zoccolo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=x49eif7p3z0.fsf@segfault.boston.devel.redhat.com \
    --to=jmoyer@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=czoccolo@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®