Date: Thu, 29 Nov 2012 11:53:06 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: "Robert N. M. Watson" <rwatson@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: Print a (rate-limited) warning when UMA zone is full. Message-ID: <20121129105306.GE1370@garage.freebsd.pl> In-Reply-To: <D7657157-0791-486D-8EF5-99488023E7ED@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121129105306.GE1370>