From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 10:44:25 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 61622285; Thu, 29 Nov 2012 10:44:25 +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 333A98FC12; Thu, 29 Nov 2012 10:44:25 +0000 (UTC) Received: from [192.168.2.119] (host86-146-118-26.range86-146.btcentralplus.com [86.146.118.26]) by cyrus.watson.org (Postfix) with ESMTPSA id 5C3C546B0C; Thu, 29 Nov 2012 05:44:24 -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: <20121129103752.GD1370@garage.freebsd.pl> Date: Thu, 29 Nov 2012 10:44:22 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121129090147.GB1370@garage.freebsd.pl> <20121129103752.GD1370@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 10:44:25 -0000 On 29 Nov 2012, at 10:37, Pawel Jakub Dawidek wrote: >> Just to follow up on some out-of-band communication -- this is a good = idea,=20 >> but there was some concern about printf() under mutexes. I'm not = actually=20 >> that concerned about that case (we do it quite a lot for warnings and = kernel=20 >> debugging), but it might be useful to consider using log() instead, = so that it=20 >> ends up in the system log as well as on the console. >=20 > I'm happy with using log(9), but currently when log(9) is used, the > message is not printed on the console, it only ends up in the system > log. printf(9) on the other hand is printed on the console and is > appended to the system logs. >=20 > The only case where log(9) will actually log to the console, AFAIR, is > when syslogd is not working. >=20 >> For I while I've wondered if we need a spp to complement pps -- that = is,=20 >> limiting printf()s to every (n) seconds, rather than (n) per second. = For=20 >> tunable warnings like this, it would be nice to limit them to once a = minute or=20 >> similar. >=20 > Or change pps to ppm. I agree that getting these warning every second = is > too aggressive. It does sound like the underlying primitives require some tweaking of = we're going to increase their use in the ways proposed. This is probably = overdue anyway. >> Finally, we should make sure that in all instances where we point at=20= >> tuning(7), it has something useful to say about the topic :-). >=20 > Yes, I am aware the warnings proposed in the patch are a bit too > optimistic:) The other fix, of course, is not to refer to tuning(7) :-). In general, providing feedback on tuning problems is a very good idea, = and something we should do more of. We should also continue to improve = our auto-tuning so that users see the warnings only infrequently. Robert=