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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
