From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 10:51:46 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 2FB324B4; Thu, 29 Nov 2012 10:51:46 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id B719E8FC13; Thu, 29 Nov 2012 10:51:45 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 0919F8D9; Thu, 29 Nov 2012 11:49:53 +0100 (CET) Date: Thu, 29 Nov 2012 11:53:06 +0100 From: Pawel Jakub Dawidek To: "Robert N. M. Watson" Subject: Re: Print a (rate-limited) warning when UMA zone is full. Message-ID: <20121129105306.GE1370@garage.freebsd.pl> References: <20121129090147.GB1370@garage.freebsd.pl> <20121129103752.GD1370@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AsxXAMtlQ5JHofzM" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) 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:51:46 -0000 --AsxXAMtlQ5JHofzM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 29, 2012 at 10:44:22AM +0000, Robert N. M. Watson wrote: >=20 > On 29 Nov 2012, at 10:37, Pawel Jakub Dawidek wrote: >=20 > >> 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 actu= ally=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 i= s,=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 m= inute or=20 > >> similar. > >=20 > > Or change pps to ppm. I agree that getting these warning every second is > > too aggressive. >=20 > 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 overd= ue anyway. So what do you think about adding ppmratecheck() next to ppsratecheck()? If a bigger change is required that will change ppsratecheck() KPI, then I'd also like to create a structure to hide 'struct timeval lastfail' and 'int curfail', eg: struct ratecheck { struct timeval rc_lastfail; int rc_curfail; }; And use this with the new ppsratecheck(). > >> 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:) >=20 > The other fix, of course, is not to refer to tuning(7) :-). This is the optimistic part I was referring to - you can't find much in tuning(7) about those sysctls/tunables. > In general, providing feedback on tuning problems is a very good idea, an= d something we should do more of. We should also continue to improve our au= to-tuning so that users see the warnings only infrequently. 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 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --AsxXAMtlQ5JHofzM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlC3PpIACgkQForvXbEpPzSnZwCg711l4bXK7vu4VnQfu82poo+c mqoAniNqu4DFinzuP4Q3b5PAApRjiauH =vOxs -----END PGP SIGNATURE----- --AsxXAMtlQ5JHofzM--