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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>