I was wondering... and thought i'd comment on something i've read... is there something going on in the kva area that's bad? (AKA exaustion through malloc routine) I found something that made me curious, and thought I'd see what you thought. I'm really debating now about what i should move my production machines to. They claim to have a patch... http://gobsd.com/node/view/39 Interested to see what everyone thinks. _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar – get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
On Wed, May 26, 2004 at 03:09:49PM -0400, lost inferno wrote:> I was wondering... and thought i'd comment on something i've read... is > there something going on > in the kva area that's bad? (AKA exaustion through malloc routine) I found > something that made me curious, and thought I'd see what you thought. I'm > really debating now about what i should move my production machines to. > They claim to have a patch... > > http://gobsd.com/node/view/39 > > Interested to see what everyone thinks.I don't know enough to judge if that patch is correct or not, but the description "very unstable" is a bit exaggerated. This is not a condition that will see your machine blowing up and falling over every ten minutes, or even every 10 days. In fact you'll only run into it if you are running your machine particularly hard and doing memory intensive things. If it was as bad as that article makes out there would be an unending series of complaining e-mails to this list, the freebsd-stable list, the freebsd-hackers list and probably any five other freebsd mailing lists you care to mention. That just hasn't happened. Remember that the whole DragonFly BSD fork was the result not just of arguments about the technical direction of the FreeBSD project, but due in part to personality conflicts and politicking between various cliques of FreeBSD developers. It's quite possible that the patches' author still has issues with some members of the FreeBSD project. By all means try out the patch provided. If you prefer, try out DragonFly BSD -- but I wouldn't go betting the whole business on it just yet. DFBSD has yet to make it's 1.0 release. Keep your production systems on one of the FreeBSD 4.x-RELEASE branches for the time being, and wait and see what happens with FreeBSD 5-STABLE and DragonFly BSD 1.0 release. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20040526/260c98bb/attachment.bin
lost inferno wrote:> I was wondering... and thought i'd comment on something i've read... is > there something going on > in the kva area that's bad? (AKA exaustion through malloc routine) I > found something that made me curious, and thought I'd see what you > thought. I'm really debating now about what i should move my production > machines to. They claim to have a patch... > > http://gobsd.com/node/view/39 > > Interested to see what everyone thinks. >Aside from the interesting words in the blog entry, I have a few problems with his patch. First of all, I can't see how it is supposed to fix anything. At line 191 we check to see if kbp->kb_next == NULL and enter a big code block to handle that. At the end of the code block (right before line 245 in his patch), we assign va = kbp->kb_next. So here we know that it is non-null. Why you need to check for it to be NULL is beyond me. But, suppose that it could be NULL. His solution is to return NULL in the M_NOWAIT case and spin in the M_WAITOK case. I assume that the point of spinning is that memory might become free at some later time via it being freed in an interrupt handler or a swapout completing. However, it does nothing to assure that enough interrpts are enable to make sure that this can happen, so the result could easily be that it spins forever. In fact. splmem() is held at that point, which is the same as splhigh(), i.e. all interrupts are blocked. So if this case is reached on a UP system, the only result will be that your get a hard system freeze, not even a panic. Regardless, I'd like to find out from David if he knows of a testable case for this. I'd be happy to entertain further discussion of that. Scott