-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have been running this kernel for about a week on an SB1000-SMP (1x900,
1x750) (sparc64) system and on a U60-SMP(2x450) system. I have just begun
a test on U2(2x400) system. So far, on SB1000 and U60, this kernel seems
as stable as anything we have seen. On U2, it is too early to tell, but
since NO 2.6.xx kernel has been stable on U1/U2 systems, I do not hold out
much hope there.
The reason for any sort of note mentioning this is the kernel's execution
characteristics on SB1000. Here there seems to be a good
news/you-might-want-a-local-mod news situation.
1. Good news: For me, at any rate, up until now programs (occasionally
gcc, but also the build of dev-lisp/sbcl-0.9.9 always, sometimes xterm)
sometimes failed with unpredictable BUS errors, SegFaults, and similar.
(Frequency was about once a day or so). I have not seen this at all for a
week, now, sbcl-0.9.9 builds fine, etc.
2. Not so good news: With this version of the kernel, kenvctrld is very
intrusive. Well, so what and what is it, anyway? kenvctrld is a kernel
module which periodically (literally) takes the system's temperature at a
couple spots, and if necessary kicks up the fan speed to keep the CPUs
from melting (and slows fans back down once temperature is lowered, or
eventually shuts the system down if things get worse). To be fair to this
kernel, I do not think kenvctrld actually managed to run with previous
kernels, but with this series, it has been restructured and is most
certainly does run.
It runs every five seconds. It takes 2 seconds with one CPU running at
100% in the system to actually read the sensors. So, with a 2-CPU system,
40% of CPU0 is dedicated to figuring out how hot the system is.
Well, that is pretty extreme. But wait! There's more! If your system
happens to be doing some actual work (like compiling something), and if
you happen to be doing interactive work using X besides, then during this
2-out-of-every-five second interval, your display gets little or no
service. (E.g., you have things like a 2-second type-ahead on the
keyboard, you move your mouse and nothing happens, things like xosview
stop. You get the idea).
There are two ways to make this a little better. First, you can build
kenvctrld as a module (CONFIG_BBC_I2C=m) and not load it. Then kenvctrld
does not run and the fans always run at top speed. If your system is in a
different room from you, this might be tolerable. If it isn't, with this
option you will go deaf.
Second, you can play with the polling interval. In the source module
drivers/sbus/char/bbc_envctrld.c, there is this definition for the polling
interval:
#define POLL_INTERVAL (5 * 1000)
With this definition, you lose about 40% of one CPU (CPU0). I have found
that I can tolerate
#define POLL_INTERVAL (5 * 1000 * 18)
which changes the interval to 90 seconds. This seems too long, but if I
am correct about earlier kernels, it is better than the "never run" we had
earlier. (Or, it could be that earlier kernels did take that 2 seconds
out of every five without killing interactive performance while doing so.)
Hope this is useful,
Regards,
Ferris
- --
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Devrel, Sparc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD69xTQa6M3+I///cRAlo8AKCxwsDRvF/O8Hy8oJWIDvDMXfHUdgCgtBRo
5Nir5e0eVpzjcXesW1K/JS8=
=Bmb2
-----END PGP SIGNATURE-----
--
gentoo-sparc@gentoo.org mailing list
Hash: SHA1
I have been running this kernel for about a week on an SB1000-SMP (1x900,
1x750) (sparc64) system and on a U60-SMP(2x450) system. I have just begun
a test on U2(2x400) system. So far, on SB1000 and U60, this kernel seems
as stable as anything we have seen. On U2, it is too early to tell, but
since NO 2.6.xx kernel has been stable on U1/U2 systems, I do not hold out
much hope there.
The reason for any sort of note mentioning this is the kernel's execution
characteristics on SB1000. Here there seems to be a good
news/you-might-want-a-local-mod news situation.
1. Good news: For me, at any rate, up until now programs (occasionally
gcc, but also the build of dev-lisp/sbcl-0.9.9 always, sometimes xterm)
sometimes failed with unpredictable BUS errors, SegFaults, and similar.
(Frequency was about once a day or so). I have not seen this at all for a
week, now, sbcl-0.9.9 builds fine, etc.
2. Not so good news: With this version of the kernel, kenvctrld is very
intrusive. Well, so what and what is it, anyway? kenvctrld is a kernel
module which periodically (literally) takes the system's temperature at a
couple spots, and if necessary kicks up the fan speed to keep the CPUs
from melting (and slows fans back down once temperature is lowered, or
eventually shuts the system down if things get worse). To be fair to this
kernel, I do not think kenvctrld actually managed to run with previous
kernels, but with this series, it has been restructured and is most
certainly does run.
It runs every five seconds. It takes 2 seconds with one CPU running at
100% in the system to actually read the sensors. So, with a 2-CPU system,
40% of CPU0 is dedicated to figuring out how hot the system is.
Well, that is pretty extreme. But wait! There's more! If your system
happens to be doing some actual work (like compiling something), and if
you happen to be doing interactive work using X besides, then during this
2-out-of-every-five second interval, your display gets little or no
service. (E.g., you have things like a 2-second type-ahead on the
keyboard, you move your mouse and nothing happens, things like xosview
stop. You get the idea).
There are two ways to make this a little better. First, you can build
kenvctrld as a module (CONFIG_BBC_I2C=m) and not load it. Then kenvctrld
does not run and the fans always run at top speed. If your system is in a
different room from you, this might be tolerable. If it isn't, with this
option you will go deaf.
Second, you can play with the polling interval. In the source module
drivers/sbus/char/bbc_envctrld.c, there is this definition for the polling
interval:
#define POLL_INTERVAL (5 * 1000)
With this definition, you lose about 40% of one CPU (CPU0). I have found
that I can tolerate
#define POLL_INTERVAL (5 * 1000 * 18)
which changes the interval to 90 seconds. This seems too long, but if I
am correct about earlier kernels, it is better than the "never run" we had
earlier. (Or, it could be that earlier kernels did take that 2 seconds
out of every five without killing interactive performance while doing so.)
Hope this is useful,
Regards,
Ferris
- --
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Devrel, Sparc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD69xTQa6M3+I///cRAlo8AKCxwsDRvF/O8Hy8oJWIDvDMXfHUdgCgtBRo
5Nir5e0eVpzjcXesW1K/JS8=
=Bmb2
-----END PGP SIGNATURE-----
--
gentoo-sparc@gentoo.org mailing list