From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 11:42:35 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6481FA3; Thu, 29 Nov 2012 11:42:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 854CF8FC08; Thu, 29 Nov 2012 11:42:35 +0000 (UTC) Received: from c0205.aw.cl.cam.ac.uk (c0205.aw.cl.cam.ac.uk [128.232.100.205]) by cyrus.watson.org (Postfix) with ESMTPSA id 74FF046B09; Thu, 29 Nov 2012 06:42:34 -0500 (EST) Subject: Re: Print a (rate-limited) warning when UMA zone is full. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <20121129110518.GF1370@garage.freebsd.pl> Date: Thu, 29 Nov 2012 11:42:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <98FCA89B-D1DF-4002-B44F-A59DCB5ED020@FreeBSD.org> References: <20121129090147.GB1370@garage.freebsd.pl> <20121129103752.GD1370@garage.freebsd.pl> <20121129105306.GE1370@garage.freebsd.pl> <0D8E588B-6FCB-4B01-9786-B5D42F16C3F0@FreeBSD.org> <20121129110518.GF1370@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1283) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 11:42:35 -0000 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=