Date: Thu, 29 Nov 2012 10:44:22 +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: <D7657157-0791-486D-8EF5-99488023E7ED@FreeBSD.org> In-Reply-To: <20121129103752.GD1370@garage.freebsd.pl> References: <20121129090147.GB1370@garage.freebsd.pl> <alpine.BSF.2.00.1211291027430.59662@fledge.watson.org> <20121129103752.GD1370@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D7657157-0791-486D-8EF5-99488023E7ED>