Re: CVS commit: src/sys/kern

[Andrew Doran <ad%homeworld.netbsd.org@localhost>]

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:
> > oki%NetBSD.org@localhost 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.