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>
index | next in thread | previous in thread | raw e-mail
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. >> >> 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: >> >> static RATECHECK(..., "foo.bar.baz", ...); >> >> Unfortunately, the tunable/sysctl mismatch makes it slightly awkward since you'd need to declare both, but I think probably worthwhile. > > 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. Roberthelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98FCA89B-D1DF-4002-B44F-A59DCB5ED020>