Date: Thu, 12 Nov 2015 18:20:08 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 204438] setsockopt() handling of kern.ipc.maxsockbuf limit Message-ID: <bug-204438-2472-wnrDUqP8xE@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-204438-2472@https.bugs.freebsd.org/bugzilla/> References: <bug-204438-2472@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204438 Alfred Perlstein <alfred@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alfred@FreeBSD.org --- Comment #13 from Alfred Perlstein <alfred@FreeBSD.org> --- I believe the reason for the adjustment is that "sb_max" is for "max kernel memory taken by the socketbuffer INCLUDING MBUFS THEMSELVES" So what is actually happening is that each MCLSIZE (size of cluster) of "data" is having MSIZE (size of mbuf) added to it. Why is it scaled up so? Because in reality one needs MSIZE actual memory for each cluster as metadata to point to it. And why is this done? So that you can actually trust "sb_max" to mean maximum kernel memory taken to support N bytes per socket. I didn't realize Linux silents truncates the requested amount, that's a little scary, however I'm learning to trust more and more what Linux does. What might make a bit more sense in the long run is actually to make: 1) kern.ipc.maxsockbuf == max number of bytes of DATA in each socketbuffer 2) kern.ipc.maxsockbufmeta = max number of bytes of DATA + METADATA required to be allocated. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-204438-2472-wnrDUqP8xE>