Re: git: eb93b99d6986 - main - in_pcb: delay crfree() down into UMA dtor
- In reply to: Gleb Smirnoff : "Re: git: eb93b99d6986 - main - in_pcb: delay crfree() down into UMA dtor"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 12 Dec 2021 13:42:08 UTC
On 1215T0713, Gleb Smirnoff wrote: > On Wed, Dec 15, 2021 at 10:47:42AM +0100, Kristof Provost wrote: > K> > My radical opinion is that per-VNET pcb zones should just be eliminated. > K> > The only thing they serve is imposing maxsockets limit separately for > K> > each VNET. But we already have the maxsocket limit on the socket zone, > K> > which is _global_! > K> > > K> > Anybody to explain me the sense of the per-VNET per-pcb zone limit > K> > set to the same maxsockets value? You can't create a pcb without a > K> > socket, which is guaranteed by the in_pcballoc() prototype. Of course > K> > I understand that pcbs may outlive the socket. But those pcbs that > K> > outlive a socket, are eventually garbage collected as their lifetime > K> > is finite. Anyway jail/VNET was never declared as a resource management > K> > framework anyway! > K> > > K> > K> rctl(8) does appear to support per-jail resource limits, but I’m not sure how complete or functional that is. > > The manual doesn't say anything about network resources. The sources > of in_pcballoc() neither suggest that any per-something resource management > is done that can prevent allocation. True. I'm guessing it should be possible to limit it via 'openfiles' resource, but there's nothing socket-specific in RCTL.