mbuf patch with sysctl suggestions too

Robert Watson rwatson at FreeBSD.org
Tue Feb 6 13:54:09 UTC 2007

On Tue, 6 Feb 2007, Mike Silbersack wrote:

> On Wed, 24 Jan 2007, Randall Stewart wrote:
>> Well.. no I believe someone (was in Lin) mentioned that you can get a 
>> live-lock if you allow a reduction.. and thus the mbuf clusters were NOT 
>> allowed to be reduced..
> I messed around with this a bit when changing the limit on 
> net.inet.tcp.maxtcptw.  It looked to me as if lowering the limit on a zone, 
> even one that has UMA_ZONE_NOFREE, worked as expected.  (As expected in the 
> UMA_ZONE_NOFREE case was that the zone could not shrink below the maximum 
> that was ever allocated in it.)
> I can see how problems could result if someone starts changing that setting 
> while the system is in some sort of mbuf exhaustion state, but I think that 
> the benefit of being able to tune it most of the time far outweighs the 
> disadvantage of things going wrong in a few cases.
> Granted, I haven't even looked at your patch, so I could be missing 
> something subtle. :)

A work-around for the "leaking" of clusters has recently been committed by 
Mohan, and is on the MFC path.  The underlying problem here is that UMA only 
partially understands the relationship between mbufs and clusters, and doesn't 
recognize that clusters cached with free mbufs (for joint allocation) are, in 
fact, free, so as the "Packet" zone cache fills, clusters for independent 
allocation are no longer seen as free.  This will hopefully correct the 
observed problems with "zoneli" wait channels and very high cluster allocation 
seen in some environments.

Robert N M Watson
Computer Laboratory
University of Cambridge

More information about the freebsd-net mailing list