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.
>
> 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().
Sounds good to me.
>>>> Finally, we should make sure that in all instances where we point at
>>>> tuning(7), it has something useful to say about the topic :-).
>>>
>>> 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) :-).
>
> 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, and something we should do more of. We should also continue to improve our auto-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.
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>