[lkml]   [2003]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.5.65-mm2
On Wed, 2003-03-19 at 15:17, jjs wrote:
> Steven P. Cole wrote:
> >I repeated the tests with 2.5.65-mm2 elevator=deadline and the situation
> >was similar to elevator=as. Running dbench on ext3, the response to
> >desktop switches and window wiggles was improved over running dbench on
> >reiserfs, but typing in Evolution was subject to long delays with dbench
> >clients greater than 16.
> >
> >I rebooted with 2.5.65-bk and ran dbench on ext3 again. Everything was
> >going smoothly, excellent interactivity, and then with dbench 28, the
> >system froze. No response to pings, no response to alt-sysrq-b (after
> >alt-sysrq-s). A hard reset was required. Nothing interesting logged.
> >Too bad. Before it crashed, 2.5.65-bk was responding to typing in an
> >Evolution new message window better than -mm2.
> >
> Just out of curiosity, what is the result of:
> cat /proc/sys/sched/max_timeslice?
> Does setting that to e.g. 50 make -mm2 smooth?
> Joe

[root@spc1 steven]# cat /proc/sys/sched/max_timeslice
[root@spc1 steven]# echo 50 >/proc/sys/sched/max_timeslice
[root@spc1 steven]# cat /proc/sys/sched/max_timeslice

Ouch. I inserted the above text saved as a file, and had to wait
over a minute after hitting the OK button. I aborted dbench which was
running 24 clients on ext3 just to finish this.

The change in max_timeslice didn't seem to improve things.

Apart from the little matter of crashing, 2.5-bk was more usable at that
and higher loads.

I'll try the different value of max_timeslice with dbench on reiserfs
next. That's where the lack of response was most evident.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:34    [W:0.117 / U:30.332 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site