Date: Thu, 11 May 2017 13:49:39 -0700 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Fabian Keil <freebsd-listen@fabiankeil.de> Cc: svn-src-all@freebsd.org Subject: Re: svn commit: r318166 - head/sys/netinet Message-ID: <20170511204939.GO1137@FreeBSD.org> In-Reply-To: <20170511125514.6714f872@fabiankeil.de> References: <201705102332.v4ANWVGW007216@repo.freebsd.org> <20170511125514.6714f872@fabiankeil.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 11, 2017 at 12:55:14PM +0200, Fabian Keil wrote: F> > Author: glebius F> > Date: Wed May 10 23:32:31 2017 F> > New Revision: 318166 F> > URL: https://svnweb.freebsd.org/changeset/base/318166 F> > F> > Log: F> > There is no good reason for TCP reassembly zone to be UMA_ZONE_NOFREE. F> > F> > It has strong locking model, doesn't have any timers associated with F> > entries. The entries theirselves are referenced only from the tcpcb F> > zone, which itself is a normal zone, without the UMA_ZONE_NOFREE flag. F> F> A side effect of the UMA_ZONE_NOFREE flag is that allocations F> with M_NOWAIT (currently used tcp_reass()) are less likely to F> fail. F> F> Removing the UMA_ZONE_NOFREE in other TCP-related parts F> "recently" caused (still unfixed) regressions like: F> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209680 F> F> It would be great if there was a method to reserve a certain F> number of items for the zone without having to rely on F> UMA_ZONE_NOFREE but last time I checked there wasn't one. Using UMA_ZONE_NOFREE for that problems is definitely a workaround. The problems should be separated, there definitely is an ipfw problem and TCP stack one. It is very strange that for an already established connection we require allocating more memory from these zones. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170511204939.GO1137>