2011/4/20 Theo de Raadt <dera...@cvs.openbsd.org>: > some of you can start cranking the kern.bufcachepercent sysctl to 90. > try it out. B be impressed, but don't report deadlocks or lockups; > however real crashes are worth knowing about. B the lockup situations > are largely understood and will be slowly worked out, which is why > this is not close to being the default.
I also did that now almost for a year, without a glitch. If anyone has some more dangerous diffs, I'm happy to test (but I have only 1G of RAM which makes it pointless for the bigmem changes I guess. Thanks for that. > the other change is that interrupt servicing times have gone down > substantially. B there are some broken drivers we will need to find I presume it's the diffs regarding return values (intr.c, vector.S and others). I asked a few people about their opinion of Message Signalled Interrupts - there's an interesting paper about interrupt routing from FreeBSD that sort of displays how fucked up this stuff on x86 really can be. Does this diff solve the problem when PCIe cardx intr() was triggered the same as ppb's? Or do we need something more? Since the road from network interrupt handlers to Xsoftintr is quite long, I guess locking issues will force you to stay to the "1 CPU for all interrupts" model for quite a while, even for hardware like ix(4). Can you describe the developer's attitude about running kernel stuff on more CPUs? Lots of hard work, or is there even more to it? > and fix, so please watch your vmstat -i numbers carefully, I never quite understood what is the "total" number useful for. For how long and how heavily has the system been used? What do you compare that to, if you use it to make some statement? Nevertheless, thanks for all the good work! -- Martin Pelikan
