zonelimit issues...

[gnn at FreeBSD.org]

At Sun, 20 Apr 2008 10:32:25 +0100 (BST),
rwatson wrote:
> 
> 
> On Fri, 18 Apr 2008, gnn at freebsd.org wrote:
> 
> > I am wondering why this patch was never committed?
> >
> > http://people.freebsd.org/~delphij/misc/patch-zonelimit-workaround
> >
> > It does seem to address an issue I'm seeing where processes get into the 
> > zonelimit state through the use of mbufs (a high speed UDP packet receiver) 
> > but even after network pressure is reduced/removed the process never gets 
> > out of that state again.  Applying the patch fixed the issue, but I'd like 
> > to have some discussion as to the general merits of the approach.
> >
> > Unfortunately the test that currently causes this is tied very tightly to 
> > code at work that I can't share, but I will hopefully be improving mctest to 
> > try to exhibit this behavior.
> 
> When you take all load off the system, do mbufs and clusters get properly 
> freed back to UMA (as visible in netstat -m)?  If not, continuing to bump up 
> against the zonelimit would suggest an mbuf/cluster leak, in which case we 
> need to track that bug.
> 

This is unclear as the process that creates the issue opens 50 UDP
multicast sockets with very large socket buffers.  I am investigating
this aspect some more.

> You might consider adding a debugging-only zonelimit waiter count to
> the UMA zone, and checks/assertions that a wakeup is being generated
> properly.  

Yes.  Do you have an example I can easily steal?

> That is, to confirm that the wakeup is generated when memory is
> freed up if there are threads waiting.  There is at least one as-yet
> MFC'd fix to the sleep/wakeup code, I believe, that might be
> relevant here.  Is the problem you're reporting on 7.x, or on 8.x?
> If 8.x, that's probably not it, but if 7.x, it could be.  (This same
> sleep/wakeup bug occasionally leads to wedging of dump(8), I
> believe).

I have seen this on 7.0 RELEASE, and STABLE and on CURRENT (8).

I am currently working on it on CURRENT because if I have a fix it's
going to have to go there first.

Best,
George