Date: Thu, 29 Nov 2012 11:42:33 +0000 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: Print a (rate-limited) warning when UMA zone is full. Message-ID: <98FCA89B-D1DF-4002-B44F-A59DCB5ED020@FreeBSD.org> In-Reply-To: <20121129110518.GF1370@garage.freebsd.pl> References: <20121129090147.GB1370@garage.freebsd.pl> <alpine.BSF.2.00.1211291027430.59662@fledge.watson.org> <20121129103752.GD1370@garage.freebsd.pl> <D7657157-0791-486D-8EF5-99488023E7ED@FreeBSD.org> <20121129105306.GE1370@garage.freebsd.pl> <0D8E588B-6FCB-4B01-9786-B5D42F16C3F0@FreeBSD.org> <20121129110518.GF1370@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29 Nov 2012, at 11:05, Pawel Jakub Dawidek wrote: > On Thu, Nov 29, 2012 at 10:56:32AM +0000, Robert N. M. Watson wrote: >> On 29 Nov 2012, at 10:53, Pawel Jakub Dawidek wrote: >>> Agreed, especially if reaching those limits is expected by the >>> administrator and he is not going to increase them. But in this case = it >>> would be even better to provide a way to turn them off. >>=20 >> I wonder if each instance of a 'ratecheck' should come with an = associated tunable/sysctl pair to allow suppression to be easily = configured. I almost find myself wondering if we want something that = looks a bit like our static SYSCTL/VFS_SET/etc declarations: >>=20 >> static RATECHECK(..., "foo.bar.baz", ...); >>=20 >> Unfortunately, the tunable/sysctl mismatch makes it slightly awkward = since you'd need to declare both, but I think probably worthwhile. >=20 > I'm afraid you lost me here. Tunable/sysctl name is not related in any > way with the warning we are printing. How can you tell > kern.ipc.maxsockets affects limits of eight different UMA zones? > Also rate-limiting is not only used to print warnings, current > ppsratecheck() function just answer the question if the limit should = be > enforced (something is happening too frequently) or not. I meant something a bit different -- I was concerned with a per-instance = sysctl/tunable to silence the warnings. For embedded systems or systems = running at peak load, occasional allocation failures may be the steady = state, in which case tuning down the rate of message printing, or simply = disabling them rather than spamming logs, may be desirable. Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98FCA89B-D1DF-4002-B44F-A59DCB5ED020>