From: Andrew Morton <akpm@digeo.com>
To: "Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: anticipatory scheduling questions
Date: Thu, 27 Feb 2003 15:26:04 -0800 [thread overview]
Message-ID: <20030227152604.334c292a.akpm@digeo.com> (raw)
In-Reply-To: <20030227222440.14610.qmail@linuxmail.org>
"Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org> wrote:
>
> Hello,
>
> I have just installed 2.5.63-mm1 on my system and have been performing a very simple benchmarks. Here are
> my first results when compared against a RedHat 2.4.20-2.54 kernel:
>
> (All times expressed as total times)
>
> 1. time dd if=/dev/zero of=/tmp/p bs=1024k count=256
> 2.5.63-mm1 -> 0m12.737s
> 2.4.20-2.54 -> 0m17.704s
It's hard to compare 2.4 and 2.5 on this one. 2.5 will start writing to disk
much earlier, and that additional I/O can sometimes get in the way of other
disk operations. The end result is that the test exits leaving more (or
less) dirty data in memory and the time for writing that out is not
accounted.
You need to either run a much longer test, or include a `sync' in the
timings.
But in this case (assuming you're using ext3), the difference is probably
explained by a timing fluke - the test on 2.4 kernel happened to cover three
ext3 commit intervals while the 2.5 test squeezed itself into two.
Hard to say - there are a lot of variables here.
> 2. time cp /tmp/p /tmp/q
> 2.5.63-mm1 -> 0m41.108s
> 2.4.20-2.54 -> 0m51.939s
Could be ext3 effects as well. Also maybe some differences in page aging
implementations.
> 3. time cmp /tmp/p /tmp/q
> 2.5.63-mm1 -> 1m7.349s
> 2.4.20-2.54 -> 0m58.966s
cmp needs to use a larger buffer ;)
> 4. time cmp /dev/zero /tmp/q
> 2.5.63-mm1 -> 0m17.965s
> 2.4.20-2.54 -> 0m14.038s
Again, depends on how much of /tmp/q was left in pagecache.
> The question is, why, apparently, is anticipatory scheduling perfomring
> worse than 2.4.20?
It doesn't seem to be from the above numbers?
> Indeed, this can be tested interactively with an application like Evolution:
> I have configured Evolution to use 2 dictionaries (English and Spanish) for
> spell checking in e-mail messages. When running 2.4.20, if I choose to reply
> to a large message, it only takes a few seconds to read both dictionaries
> from disk and perform the spell checking.
> However, on 2.5.63-mm1 the same process takes considerably longer. Any
> reason for this?
Could you boot with elevator-deadline and retest?
How large are the dictionary files?
next prev parent reply other threads:[~2003-02-27 23:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-27 22:24 anticipatory scheduling questions Felipe Alfaro Solana
2003-02-27 23:26 ` Andrew Morton [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-02-28 12:18 Felipe Alfaro Solana
2003-02-28 12:44 ` Andrew Morton
2003-02-28 14:38 Felipe Alfaro Solana
2003-02-28 19:14 ` Andrew Morton
2003-02-28 23:12 Felipe Alfaro Solana
2003-02-28 23:16 ` Andrew Morton
2003-03-01 10:25 Felipe Alfaro Solana
2003-03-01 10:40 ` Andrew Morton
2003-03-01 11:51 ` David Lang
2003-03-01 17:15 ` Alan Cox
[not found] <fa.g5ol5kg.cgoq0g@ifi.uio.no>
[not found] ` <fa.hp882fv.1u0orj9@ifi.uio.no>
2003-03-01 12:48 ` Ed Tomlinson
2003-03-01 14:48 Felipe Alfaro Solana
2003-03-02 11:40 Felipe Alfaro Solana
2003-03-02 20:43 ` Andrew Morton
2003-03-02 21:50 Felipe Alfaro Solana
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=20030227152604.334c292a.akpm@digeo.com \
--to=akpm@digeo.com \
--cc=felipe_alfaro@linuxmail.org \
--cc=linux-kernel@vger.kernel.org \
/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