From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 10:56:35 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 90173591; Thu, 29 Nov 2012 10:56:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5E53E8FC14; Thu, 29 Nov 2012 10:56:35 +0000 (UTC) Received: from [192.168.2.119] (host86-146-118-26.range86-146.btcentralplus.com [86.146.118.26]) by cyrus.watson.org (Postfix) with ESMTPSA id 8119846B0C; Thu, 29 Nov 2012 05:56:34 -0500 (EST) Subject: Re: Print a (rate-limited) warning when UMA zone is full. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <20121129105306.GE1370@garage.freebsd.pl> Date: Thu, 29 Nov 2012 10:56:32 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0D8E588B-6FCB-4B01-9786-B5D42F16C3F0@FreeBSD.org> References: <20121129090147.GB1370@garage.freebsd.pl> <20121129103752.GD1370@garage.freebsd.pl> <20121129105306.GE1370@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1283) 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:56:35 -0000 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=