Contributed by sean on from the when you got nothing better to do... spin dept.
An interesting report from Bob Beck has been posted on KernelTrap.org. It seems that, while chasing problems on RAID performances, the merry hackers of the hackaton have been able to correct several problems in the OpenBSD kernel idle loop... leading to performance improvements. A very interesting read.
(Comments are closed)
By Anonymous Coward (60.225.120.80) on
Comments
By Anonymous Coward (68.104.57.241) on
Comments
By Brad (216.138.195.228) brad at comstyle dot com on
By Anthony Roberts (68.145.103.21) on
Will patches be released for stable releases?
Comments
By Nate (65.94.62.132) on
Comments
By Anthony Roberts (68.145.103.21) on
Comments
By Brad (209.5.161.201) brad at comstyle dot com on
Comments
By Anthony Roberts (68.145.103.21) on
By Brad (209.5.161.201) brad at comstyle dot com on
Comments
By Anthony Roberts (68.145.103.21) on
By Anonymous Coward (142.166.106.18) on
Comments
By rene (138.217.63.30) on
Comments
By Brad (209.5.161.201) brad at comstyle dot com on
Comments
By Anonymous Coward (131.202.168.108) on
Comments
By tedu (209.5.161.201) on
Comments
By Anonymous Coward (131.202.168.108) on
By Matt (195.92.109.20) on
in the /sys/arch/i386/i386 directory...
update apm.c to 1.65.
update locore.s to 1.89, but remove the change from 1.87 to 1.88.
update mptramp.s to 1.3.
By Yusuf Goolamabbas (61.10.7.21) on
Comments
By Anonymous Coward (209.5.161.201) on
By Anonymous Coward (66.92.213.187) on
By Markus Hennecke (80.144.233.5) on
Am I the only one seeing this effect? I did not have the time to look through the changes to find the cause of this, though.
By Daniel Tams (83.72.196.169) on http://dantams.sdf-eu.org/
I have always thought it was an April's Fools joke, as I thought there is no use in optimizing the idle loop, as it is supposed to kill time. But given this new article on the same subject, and the fact that there is no slightest hint in the article that it is a joke, I would like to know for sure.
Comments
By Jim (198.62.124.245) on
By Anonymous Coward (66.110.114.5) on
Before the commit, It used to reboot and do a nice halt (no powerdown), but after the commit it doesn't even reboots freezing on the "rebooting" message.
Question is: how to debug if the problem is the code, me or the laptop itself?
Comments
By tedu (209.5.161.201) on
Comments
By Anonymous Coward (66.110.114.5) on
I surely want to fill a PR about this, but I don't know how to technicaly describe the error.
As I have told, it hangs in the "rebooting..." line. I don't have any
idea of how to get any more information from the kernel. Please point
me to some docs related to this so I can try getting this and fill the PR.
Comments
By pedro (209.5.161.201) on
By m0rf (68.104.57.241) on
Comments
By Anonymous Coward (80.56.207.237) on
Comments
By pedro (209.5.161.201) on
or, preferably, look at the code itself
Comments
By Anonymous Coward (71.0.126.14) on
Comments
By pedro (209.5.161.201) on
http://ambientworks.net/~pedro/why.tgz
Comments
By Sam (130.88.31.6) on
By Anthony Roberts (68.145.103.21) on
Comments
By tedu (209.5.161.201) on
Comments
By Anthony Roberts (68.145.103.21) on
I left extra space on the disk when I partitioned it, but that was long ago. I was fortunate to have a partition that was big enough and that I didn't need anymore, I'm curious what a better way is for next time.
By Matt (213.208.100.201) on
mount -t nfs -o ro localhost:/stuff .../httpd/.../stuff
or something like that. Not sure about the performance though, or stability. I was going to check it out at the weekend.
By m0rf (68.104.57.241) on
By petruha (80.81.40.160) on http://petruha.bsd.lv/
By Simon (130.225.194.192) on
Maybe it's good that union and null are gone, maybe it will force people to plan their filsystem layout better.
Comments
By Matt (195.92.109.20) on
Getting NFS exports to behave is another problem in which I would like flexibility.
By mirabile (213.196.240.143) on http://MirBSD.org/