Print a (rate-limited) warning when UMA zone is full.

[Robert N. M. Watson]

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