On Fri, Oct 15, 2010 at 10:33:22PM +0000, Andrew Doran wrote: > On Fri, Oct 15, 2010 at 05:30:52PM +0100, Mindaugas Rasiukevicius wrote: > > o...@netbsd.org wrote: > > > In M_WAIT case, m_reclaim() will run and run until get mbuf cluster > > > if mclpool limit reached. If m_reclaim() repeatedly but cannot to > > > get new mbuf cluster, m_clget() will not return. > > > > > > network stacks using mbufs is use with M_DONTWAIT, but it will failed > > > to get new mbuf cluster in this case. "freeze" means that. > > > > Yes, hitting the limit would trigger m_reclaim() and m_clget() would > > block. It is a quite similar condition to memory or KVA starvation. > > However, why such blocking in sosend() is problematic, or, how is it > > different from any other WAITOK allocation? > > > > I see the point about the limit. Inadequately low limit may cause many > > blocking processes, while there is still a lot of memory. However, in > > such case, perhaps you want PR_LIMITFAIL, instead of PR_NOWAIT? Note > > that PR_NOWAIT (M_DONTWAIT) has other implications, e.g. it might fail > > due to try-locks. So, I think your fix is incorrect. > > Agreed. NOWAIT should almost never be used from thread/process context, > it indicates that an underlying problem is not being tackled properly. > In this case it may introduce sporadic and hard to reproduce failures. > If we're not going to fix the reclaim problem in the near future I suggest > it's better to change this back to WAITOK.
Has this been fixed? The least objectionable hack that I can see would be to add an analogue of PR_LIMITFAIL. Thanks.