From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 01:22:20 2014 Return-Path: Delivered-To: freebsd-hackers@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 D1CADC3A for ; Thu, 30 Oct 2014 01:22:20 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6ABB07A6 for ; Thu, 30 Oct 2014 01:22:20 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id x12so2597996wgg.31 for ; Wed, 29 Oct 2014 18:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-type:content-disposition:user-agent; bh=e0KJW92dDY7s4c6HDQFqIEletGMe2wQC9+7L/FzQrrY=; b=S88qfonIMGK4KpeuwNXIwlON/ld1Z1O8IixexzA4qg9zbit1RAQtX/fsDA1Bf0vUgQ E4cKxaHyyDwv09LPxoiB8oHEm2hzIS9gdCCY+cVuGq7tsC/M7nF0VJdW1eV8FLvHD0lV FntHFFEff+eTVdjJS/F93YmxNR3zkDlp9ueZ7r7PyyZDhJSvEbJc/ub8nXpei9flxPEY RuJPd9ESbyqh9EtTU6HMCNG2yIIC/NvZeSpzQClRU+u0xo/zB0m7aLDyJ8P7PfrF8qzy rWgaRNAIP3FgsuxCg0fcsoXQggGK0gtb7WuATvo2x4tUkv1JwTSzrER7F76YvbnltPyj oNUA== X-Received: by 10.180.90.65 with SMTP id bu1mr16242083wib.71.1414632138632; Wed, 29 Oct 2014 18:22:18 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id hu3sm6976537wjb.17.2014.10.29.18.22.17 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 29 Oct 2014 18:22:17 -0700 (PDT) Date: Thu, 30 Oct 2014 02:22:15 +0100 From: Mateusz Guzik To: freebsd-hackers@freebsd.org Subject: struct filedesc0 eats > 1024 bytes Message-ID: <20141030012215.GB25368@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 01:22:20 -0000 Since it is allocated from general slab and is > 1024 bytes in size, it actually occupies 2048 bytes. NDFILE is 20. struct filedesc0 { struct filedesc fd_fd; SLIST_HEAD(, freetable) fd_free; struct filedescent fd_dfiles[NDFILE]; NDSLOTTYPE fd_dmap[NDSLOTS(NDFILE)]; }; (kgdb) p sizeof(struct filedesc) $1 = 120 (kgdb) p sizeof(struct filedesc0) $2 = 1096 (kgdb) p sizeof(struct filedescent) $3 = 48 Unfotunately there is no way to reoder elements in included structs to gain enough space (or at least I didn't find any). Maybe it may be a good idea to reconsider going back to "capability fd" which is an intermediate object in the future. Next allocation is at 32 fds and that eats over 1500 bytes. In the meantime I propose decreasing NDFILE by 2. This gives sizeof = 1000 and leaves 24 bytes for possible future additions. In linux they use 32 as their default, which would still keep us within this 2KB object. But it seems similarly arbitrary. -- Mateusz Guzik