From owner-freebsd-arch@FreeBSD.ORG Mon Apr 13 09:47:11 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DD4FC67 for ; Mon, 13 Apr 2015 09:47:11 +0000 (UTC) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 99540D6E for ; Mon, 13 Apr 2015 09:47:10 +0000 (UTC) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id EA82A4201B1; Mon, 13 Apr 2015 19:47:00 +1000 (AEST) Date: Mon, 13 Apr 2015 19:46:59 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Poul-Henning Kamp Subject: Re: default file descriptor limit ? In-Reply-To: <79209.1428913320@critter.freebsd.dk> Message-ID: <20150413190438.X1619@besplex.bde.org> References: <78759.1428912996@critter.freebsd.dk> <79209.1428913320@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=ZuzUdbLG c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=EA5itrwUPoEA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=ZUNhNLIQv5YCmnLs6wMA:9 a=CjuIK1q_8ugA:10 Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 09:47:11 -0000 On Mon, 13 Apr 2015, Poul-Henning Kamp wrote: > -------- > In message <78759.1428912996@critter.freebsd.dk>, Poul-Henning Kamp writes: >> $ limits >> Resource limits (current): >> [...] >> openfiles 462357 >> >> say what ? >> >> This wastes tons of pointless close system calls in programs which >> use the suboptimal but best practice: >> >> for (i = 3; i < sysconf(_SC_OPEN_MAX); i++) >> close(i); sysconf() takes about as long as a failing close(), so best practice is to cache the result of sysconf(). Best practice also requires error checking. >> For reference Linux seems to default to 1024, leaving it up to >> massive server processes to increase the limit for themselves. >> >> I'm all for autosizing things but this is just plain stupid... I would have used the POSIX/C limit of 20 for the default, leaving it up to mere bloatware to increase the limit. It is too late for that. Next best is a default of RLIM_INFINITY. In FreeBSD-1, RLIM_INFINITY was only 32 bits, so was only 5 times larger than the above. Now it is 64 bits, so it is 20 billion times larger. Getting the full limit also requires a 64-bit system, since sysconf() only returns long. sysconf(_SC_OPEN_MAX) doesn't even work on 32-bit systems if the limit is above LONG_MAX. > Just to give an idea how utterly silly this is: > > #include > #include > > int > main(int c, char **v) > { > int i, j; > > for (j = 0; j < 100; j++) > for (i = 3; i < sysconf(_SC_OPEN_MAX); i++) > close(i); > return (0); > } > > Linux: 0.001 seconds > FreeBSD: 17.020 seconds 1 millisecond is a lot too. For full silliness: - optimize as above so that this takes half as long - increase the defaullt so that it takes 20 billion times longer. 17.020 / 2 * 20 billion seconds = 5393+ years. > PS: And don't tell me to fix all code in /usr/ports to use closefrom(2). I don't see any way to fix ports. I few might break with the limit of 1024. The only good thing is that the Linux limit is not very large and any ports that need a larger limit have probably been made to work under Linux. Worse but correct practice is the use the static limit of OPEN_MAX iff it is defined. Only broken systems like FreeBSD define it if the static limit is different from the dynamic limit. In FreeBSD, it is 64, so naive software that trusts the limit gets much faster loops than the above without really trying. libc sysconf() has poor handling of unrepresentable rlimits in all cases (just 2 cases; the other one is _SC_CHILD_MAX. The static limit CHILD_MAX is broken by its existence in FreeBSD in the same way as OPEN_MAX): X case _SC_OPEN_MAX: X if (getrlimit(RLIMIT_NOFILE, &rl) != 0) X return (-1); X if (rl.rlim_cur == RLIM_INFINITY) X return (-1); This is not an error, just an unrepresentable limit. This fails to set errno to indicate the error (getrlimit() didn't since this is not an error). This works in practice because it is unreachable -- the kernel clamps this particular rlimit, so RLIM_INFINITY is impossible. X if (rl.rlim_cur > LONG_MAX) { X errno = EOVERFLOW; X return (-1); X } As above, except it sets errno. If this were reachable, then it would cause problems for buggy applications that don't check for errors. But this case shouldn't be an error. LONG_MAX file descriptors should be enough for anybloatware. When 32-bit LONG_MAX runs out, the bloatware can simply require a 64-bit system. X return ((long)rl.rlim_cur); Bruce