Re: CVS commit: src/sys/kern

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

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.