After I rebooted my 2.0.30 desktop after 15 days of uptime to
test 2.0.31-pre3 in order to deliver my part of testing kernels,
I was sure that something would crash and that I would regret
doing it but au contraire I am more than pleased with the new
kernel and it seems noticably faster than 2.0.30. Uptime is
more than 4 days now and I haven't changed my habits so I'm
still doing the same thing I used to do on 2.0.30 and the
2.0.31-pre3 kernel seems amazingly usable.
Now, I have no bugs to report (I must belong to the minority?
of Linux users since the only oops I have encountered in more
than two years of Linuxing was on a 1.3.70 or something) but I
do wonder one particular thing: vmstat reports that there are
a lot of more context switches/sec then there was on 2.0.30
samkaski@pasuuna:~$ vmstat
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
2 0 0 17772 3920 836 4940 0 0 6 1 55 73 7 1 92
samkaski@pasuuna:~$
I'm currently running X (netscape, 5 xterm's), playing MP3 and
spectatoring QW on a p5-100/32 . With the same setup on 2.0.30
the cs-field had usually 3-9. Has something changed dramatically
in Linux scheduling since 2.0.30 or do I have a problem on my
hands? Our departments mainserver that is running 2.0.29 has 5-13
in cs-field despite more than 10 users currently non-idle, so I'm
not just imaging things.
Furthermore, when flush/sync is run the kernel seems to do
2-5 runs in a 10 sec timeframe on disk compared to the 1-3 in
a 5 sec timeframe to which I got used with 2.0.30 so I suspect
there have been some severe MM-changes too? Yes, I'm a awfully
paranoid person that notices/hears when the SCSI disk gets 2x
more activity on sync/flush then what it used to get.
Again, I wish to thank again all people participating in kernel
development.
-- Samuli Kaski, samkaski@cs.helsinki.fi Department of Computer Science, University of Helsinki, Finland.