From owner-freebsd-testing@FreeBSD.ORG Thu Mar 6 11:23:31 2014 Return-Path: Delivered-To: freebsd-testing@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC917E77 for ; Thu, 6 Mar 2014 11:23:31 +0000 (UTC) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id 82D8339E for ; Thu, 6 Mar 2014 11:23:31 +0000 (UTC) Received: (qmail 55040 invoked from network); 6 Mar 2014 11:23:23 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay02.pair.com with SMTP; 6 Mar 2014 11:23:23 -0000 X-pair-Authenticated: 87.58.146.155 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id s26BNMU3015482; Thu, 6 Mar 2014 12:23:23 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id s26BNMw9015481; Thu, 6 Mar 2014 12:23:22 +0100 (CET) (envelope-from pho) Date: Thu, 6 Mar 2014 12:23:22 +0100 From: Peter Holm To: Alan Somers Subject: Re: Test scenario for sysctl kern.maxfiles Message-ID: <20140306112322.GA10664@x2.osted.lan> References: <20140305085806.GA70478@x2.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-testing@freebsd.org" X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 11:23:31 -0000 On Wed, Mar 05, 2014 at 10:08:49AM -0700, Alan Somers wrote: > On Wed, Mar 5, 2014 at 1:58 AM, Peter Holm wrote: > > Here's an attempt to verify that increasing kern.maxfiles works as > > expected. > > > > http://people.freebsd.org/~pho/kern_descrip_test-v3.diff > > -- > > Peter > > 1) done should be of type "static volatile sig_atomic_t", not int, > because it's set by signal handlers. > Yes, that is nicer (I learned something new today :-). But the use here works because there is a call to usleep(3) after each test, forcing the compiler to reload the "done" variable. > 2) using atexit() to register a cleanup routing is a hack. No doubt Why do you say that using atexit(3) is a hack? > you already noticed that it's difficult to use Kyua's builtin cleanup > capabilities because of the need to pass the value of oldmaxfiles. I > too have experienced that frustration. Is there any way to pass > values from the body of a testcase to its cleanup? Using > atf_tc_set_md_var() would be one way, but the man page suggests that > that function cannot be called from the body. Julio, is there a > better way to do this? > > 3) Why do you openfiles(oldmaxfiles + 50, 0) instead of just > openfiles(oldmaxfiles) ? It seems that the latter would also verify > the assertion. > The idea is to test "expansion" -> expand maxfiles to maxfiles + 1000 and test "more than was possible before". But that of cause only works on a moderately loaded host. > 4) openfiles(oldmaxfiles + 50, 0) will fail if there are already 950 > open files. A quick check on freefall showed that kern.openfiles was > 935. Perhaps you should try opening openfiles(oldmaxfiles - > kern.openfiles + 50, 0). That wouldn't be perfect, due to races, but > it would be better. > Yes I agree, that would be better. Now this raises an interesting question for me: Which environment do you guys expect ATF to run in? If it is hosts like freefall, any resource hogging tests are out of the question I would think. -- Peter