From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Antti Lankila <alankila@elma.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: elevator=as related to my 2.6 performance issues
Date: Mon, 19 Apr 2004 10:37:35 +1000 [thread overview]
Message-ID: <40831F4F.1000406@yahoo.com.au> (raw)
In-Reply-To: <Pine.A41.4.58.0404181621140.42820@tokka.elma.fi>
Hi Antti,
Sounds pretty serious. What happens if you set
/sys/block/*/queue/iosched/antic_expire to 0 while
using elevator=as?
Antti Lankila wrote:
> I whined a couple of weeks back with stalling USB and PS/2 mice... I seem to
> have accidentally found a workaround around the issue.
>
> I switched to elevator=deadline the other day and found that it solved my
> issues with stalling USB mice that I'm seeing on 3 computers. Overall the
> system behaves very responsively now during IDE load, none of the bad
> behaviour such as:
>
> - system is something like 80 % idle but still no events from USB or PS/2
> mice appear in /dev/psaux, thus mouse doesn't move for prolonged periods.
> I've measured the mouse to stop moving for up to 10 seconds.
>
> - when apt-get dist-upgrade or updatedb is running, games like ut2004 start
> to stall so much everything gets unplayable. You don't expect
> /usr/bin/find to cause too much load. On the contrary, you would expect it
> to be hardly noticeable.
>
> I've seen this on 3 computers now, which have been based on KT266, KT333 and
> Nforce2. Kernels have been 2.6.3-1-k7 (Debian sarge) and 2.6.5 (custom
> compiled).
>
> I tried elevator=deadline because I got tired of the unacceptable
> performance I was seeing from 2.6 and tried to come up with some kind of
> numbers with bonnie++ to prove that 'hey, look there, that's the problem'.
> Bonnie++ numbers with 2.6 AS looked just fine though, CPU usage was down,
> although throughput was not so good as with 2.4 (about 10 % overall
> degradiation in the "intelligent" read and write, but per-char results were
> much better). However, with deadline I got a clear improvement over 2.4 in
> the numbers and the behaviour during bonnie++.
>
> These experiences suggests that I until this get solved I'm going to keep
> anticipatory scheduler off. Either it's directly responsible or just brings
> out some misbehaviour in another place. And yes, I have machines where AS
> never appears to cause any particular kind of trouble, so I got no idea
> what's really wrong. Other people who have had this kind of issues might
> want to try the same trick and report with results.
>
> Antti
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
prev parent reply other threads:[~2004-04-19 0:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-18 13:23 elevator=as related to my 2.6 performance issues Antti Lankila
2004-04-19 0:37 ` Nick Piggin [this message]
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=40831F4F.1000406@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=alankila@elma.net \
--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