mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Matthew <jackdachef@gmail.com>
To: "Ingo Molnar" <mingo@elte.hu>
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: performance "regression" in cfq compared to anticipatory, deadline and noop
Date: Sat, 10 May 2008 21:18:04 +0200	[thread overview]
Message-ID: <e85b9d30805101218u4b8f0c2bw47af2384133a5c77@mail.gmail.com> (raw)

Hi Ingo, hi everybody,

I've encountered sort of a performance "regression" in using cfq (and
the cfq-based bfq) in comparison with the other io-schedulers:

1) interactivity during load is much better compared to the others
(thanks a lot for that, that made me appreciate this scheduler) BUT
2) everything seems to take somewhat longer to load (big applications
like firefox, etc. )
3) hdparm shows the same behavior

since I've started using cfq only for a few days (approx. 1-2 weeks
now) I didn't really notice it until I tested "performance" via
hdparm:


/dev/sdd:
 Timing buffered disk reads:  308 MB in  3.01 seconds = 102.22 MB/sec

/dev/sdd:
 Timing buffered disk reads:  306 MB in  3.01 seconds = 101.66 MB/sec

/dev/sdd:
 Timing buffered disk reads:  304 MB in  3.02 seconds = 100.77 MB/sec
noop [anticipatory] deadline cfq

deadline & noop are similar, the test of noop finishes pretty fast ...


/dev/sdd:
 Timing buffered disk reads:  170 MB in  3.02 seconds =  56.27 MB/sec

/dev/sdd:
 Timing buffered disk reads:  176 MB in  3.02 seconds =  58.21 MB/sec

/dev/sdd:
 Timing buffered disk reads:  176 MB in  3.02 seconds =  58.22 MB/sec
noop anticipatory deadline [cfq]

this behavior occurs on an jmicron sata-controller (JMB363/361) and
the probably the 4th port of the Intel ICH7R but only with cfq
selected, the first (?) and second (?) port of the Intel ICH7R are
fine performance-wise, don't know why it's that picky
with the other schedulers it's fine

I've tested: 2.6.24-gentoo-r7 (+ 2.6.24.7), 2.6.24-gentoo-r3, 2.6.25,
2.6.25.2 (+ 2.6.25-zen1), 2.6.25-rc8, the kernel of the ubuntu
desktop-livecd amd64 (ubuntu 8.04) (cfq enabled)
all show this worse "performance" compared to the other schedulers
all kernels are amd64 on gentoo ~amd64, glibc-2.7.1, gcc-4.2.3 hardened

hardware:
Asus P5W DH Deluxe

I unfortuantely can't test earlier kernel-versions due to the fact
that I'm using reiser4 for /(root) and the earlier kernels + reiser4
aren't that stable in terms of data safety

hopefully this is reproducable & you guys can explain if this is
something to "worry" about (performance) and/or a real regression or
just some kind of placebo effect

Many thanks in advance & thanks a lot for this great scheduler (cfq;
I'm looking forward to bfq in mainline which seems to work even better
under load)

Regards

Mat

             reply	other threads:[~2008-05-10 19:18 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-10 19:18 Matthew [this message]
     [not found] ` <20080510200053.GA78555@gandalf.sssup.it>
2008-05-10 20:39   ` Matthew
2008-05-10 21:56     ` Fabio Checconi
2008-05-11  0:00     ` Aaron Carroll
2008-05-11 13:14 Daniel J Blueman
2008-05-11 14:02 ` Kasper Sandberg
2008-05-13 12:20   ` Jens Axboe
2008-05-13 12:58     ` Matthew
2008-05-13 13:05       ` Jens Axboe
     [not found]         ` <e85b9d30805130842p3a34305l4ab1e7926e4b0dba@mail.gmail.com>
2008-05-13 18:03           ` Jens Axboe
2008-05-13 18:40             ` Jens Axboe
2008-05-13 19:23               ` Matthew
2008-05-13 19:30                 ` Jens Axboe
2008-05-14  8:05               ` Daniel J Blueman
2008-05-14  8:26                 ` Jens Axboe
2008-05-14 20:52                   ` Daniel J Blueman
2008-05-14 21:37                     ` Matthew
2008-05-15  7:01                       ` Jens Axboe
2008-05-15 12:21                         ` Fabio Checconi
2008-05-16  6:40                           ` Jens Axboe
2008-05-16  7:46                             ` Fabio Checconi
2008-05-16  7:49                               ` Jens Axboe
2008-05-16  7:57                                 ` Jens Axboe
2008-05-16  8:53                                   ` Daniel J Blueman
2008-05-16  8:57                                     ` Jens Axboe
2008-05-16 15:23                                       ` Matthew
2008-05-16 18:39                                         ` Fabio Checconi
2008-08-24 20:24                           ` Daniel J Blueman
2008-08-25 20:29                             ` Fabio Checconi
2008-08-25 15:39                               ` Daniel J Blueman
2008-08-25 17:06                                 ` Fabio Checconi
2008-12-09 15:14                                   ` Daniel J Blueman
     [not found]                   ` <e85b9d30805140332r3311b2d6r6831d37421ced757@mail.gmail.com>
     [not found]                     ` <e85b9d30805140334q69cb5eacued9a719414e73d53@mail.gmail.com>
     [not found]                       ` <20080514103956.GD16217@kernel.dk>
     [not found]                         ` <e85b9d30805141239g5df9abc6i666b1f621d632b44@mail.gmail.com>
     [not found]                           ` <e85b9d30805161549o7c8f065do24b6567e2ade0afa@mail.gmail.com>
2008-05-19 10:39                             ` Matthew
2008-05-13 13:51     ` Kasper Sandberg
2008-05-14  0:33       ` Kasper Sandberg

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=e85b9d30805101218u4b8f0c2bw47af2384133a5c77@mail.gmail.com \
    --to=jackdachef@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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®