Date: Thu, 29 Nov 2012 10:56:32 +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: <0D8E588B-6FCB-4B01-9786-B5D42F16C3F0@FreeBSD.org> In-Reply-To: <20121129105306.GE1370@garage.freebsd.pl> 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> <20121129105306.GE1370@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29 Nov 2012, at 10:53, Pawel Jakub Dawidek wrote:
>> 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.
>=20
> So what do you think about adding ppmratecheck() next to =
ppsratecheck()?
>=20
> 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:
>=20
> struct ratecheck {
> struct timeval rc_lastfail;
> int rc_curfail;
> };
>=20
> And use this with the new ppsratecheck().
Sounds good to me.
>>>> 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) :-).
>=20
> This is the optimistic part I was referring to - you can't find much =
in
> tuning(7) about those sysctls/tunables.
>=20
>> 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.
>=20
> 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.
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:
static RATECHECK(..., "foo.bar.baz", ...);
Unfortunately, the tunable/sysctl mismatch makes it slightly awkward =
since you'd need to declare both, but I think probably worthwhile.
Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0D8E588B-6FCB-4B01-9786-B5D42F16C3F0>