On Wed, Oct 13, 2010 at 08:08:34PM -0400, Ted Unangst wrote: > So it's not a good idea to perform long lasting operations in the kernel. > The scheduler doesn't deal well with it and nobody else gets to run. > > One of those long loops is loading a large table into pf. If you're > lucky, you'll run out of memory and pool will finally sleep. > > I stuck a couple yield() calls into the long loops after sufficient > iteration. > > I also zapped PFR_FLAG_ATOMIC because it's not really atomic anyway. I > also couldn't find any callers. Leftover? Mixing two things in the same diff, like this isn't helpful. Specially since the zapping of this flag is 80% of this diff or so. > Another thing to fix at some point is that we call splsoftnet and splx > multiple times per address in some cases, but fixing that was getting too > complicated and requires some more code shuffling. Different thing.
> + if (++n % 1000 == 0) > + yield(); While I see the point. This just screams "HACK!". Not sure if this helps. Might be better to do this to something thats way eaiser to instrument, maybe something similar to what the guy on misc@ was hitting with /dev/urandom. my two cents (note, they are icelandic cents and so not really worth anything! ;)
