Date: Sat, 8 Dec 2012 14:24:03 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r243999 - head/sys/kern Message-ID: <20121208133242.U995@besplex.bde.org> In-Reply-To: <201212072230.qB7MUUnY098797@svn.freebsd.org> References: <201212072230.qB7MUUnY098797@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 7 Dec 2012, Pawel Jakub Dawidek wrote:
> Log:
> Configure UMA warnings for the following zones:
> - unp_zone: kern.ipc.maxsockets limit reached
> - socket_zone: kern.ipc.maxsockets limit reached
These still have part of the poor grammar, with a redundant "limit".
I thought that the limit on the number of sockets was on the total
number of sockets. The documentation of its sysctl in sysctl -d still
doesn't say that it is only a per-zone limit (unless you changed this
recently):
kern.ipc.maxsockets: Maximum number of sockets avaliable
This also misspells "available".
Its documentation in man pages is still null (except the tcp(4) refers
to it when documenting net.inet.tcp.maxtcptw) unless you changed this
recently.
> - zone_mbuf: kern.ipc.nmbufs limit reached
> - zone_clust: kern.ipc.nmbclusters limit reached
> - zone_jumbop: kern.ipc.nmbjumbop limit reached
> - zone_jumbo9: kern.ipc.nmbjumbo9 limit reached
> - zone_jumbo16: kern.ipc.nmbjumbo16 limit reached
Same bug, except the sysctl names are missing "lim" or "max" and repeating
"limit" works around this bug a little. They are all for limits on
numbers, but there names only say "n" (number). Anyone should think that
nmbufs gives the current number of mbufs allocated, but it actually gives
the limit on the number. AFAIK there is no simple integer sysctl giving
the number allocated. The descriptions of these sysctls in sysctl -da
are not missing "Maximum", but are otherwise gratuitously different from
descriptions of other limits:
% kern.ipc.maxsockbuf: Maximum socket buffer size
% kern.ipc.max_linkhdr: Size of largest link layer header
% kern.ipc.max_protohdr: Size of largest protocol layer header
% kern.ipc.max_hdr: Size of largest link plus protocol header
% kern.ipc.max_datalen: Minimum space left in mbuf after max_hdr
"lim[it]" is never used in names under kern.ipc. There is no consistency
for the underscore after "max".
% kern.ipc.nmbclusters: Maximum number of mbuf clusters allowed
% kern.ipc.nmbjumbop: Maximum number of mbuf page size jumbo clusters allowed
% kern.ipc.nmbjumbo9: Maximum number of mbuf 9k jumbo clusters allowed
% kern.ipc.nmbjumbo16: Maximum number of mbuf 16k jumbo clusters allowed
% kern.ipc.nmbuf: Maximum number of mbufs allowed
Bad names, and these are the only limits that are described as being
"allowed". It should go without saying that limits cannot be exceeded
because something doesn't allow this.
% kern.ipc.maxpipekva: Pipe KVA limit
"limit" is a non-verbose way of saying "maximum [or minimum] number of".
It it rarely used.
% kern.ipc.msgmax: Maximum message size
% kern.ipc.msgmnb: Maximum number of bytes in a queue
Here "max" is abbreviated to "m".
% kern.ipc.msgtql: Maximum number of messages in the system
Here "max" is missing.
% kern.ipc.semmns: Maximum number of semaphores in the system
% kern.ipc.semmnu: Maximum number of undo structures in the system
% kern.ipc.semmsl: Max semaphores per id
% kern.ipc.semopm: Max operations per semop call
% kern.ipc.semume: Max undo entries per process
Most msg/sem/shm sysctls abbreviate "max" to "m", but they are very
inconsistent in the placement of the "m".
It is a style bug to abbreviate to "Max" in the description, especially
in subsystems which also use "Maximum". On freefall now, in sysctl
-nda output, there are 92 lines with case-insensitive matches to
"maximum" and another 53 lines which on match "max" case-insensitively.
% kern.ipc.semvmx: Semaphore maximum value
This seems to abbreviate to "mx". The "v" is probably important, but
is not described.
The "[Mm]ax[imum] in the description probably shouldn't be disordered to
match the "m[ax]" in the sysctl name as it is here. On freefall now,
75 of the 92 case-insensitive "maximum"s are in a normal form with the
description starting with "Maximum" and another 3 in a not so normal form
with the description starting with "maximum".
% kern.ipc.semaem: Adjust on exit max value
% kern.ipc.shmmax: Maximum shared memory segment size
% kern.ipc.shmall: Maximum number of pages available for shared memory
% kern.ipc.soacceptqueue: Maximum listen socket pending connection accept queue size
% kern.ipc.maxsockets: Maximum number of sockets avaliable
Apart from being misspelled, "available" is misleading (I think). This is
just a fairly arbitrary limit, like the ones that say "allowed". It is
probably not even true that the maximum number is always available, since
vm may be overcommitted so that not all limits are simultaneously
reachable. "Available" is only correct for something like a number of
preallocated buffers in a buffer pool. It would only be correct for
a limit if buffers up to the limit are preallocated, and that is rarely done.
% kern.ipc.nsfbufs: Maximum number of sendfile(2) sf_bufs available
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121208133242.U995>