All of lore.kernel.org
 help / color / mirror / Atom feed
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/
> 


      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.