From owner-svn-src-all@FreeBSD.ORG Fri Apr 24 12:37:23 2015 Return-Path: Delivered-To: svn-src-all@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 5CE3E358; Fri, 24 Apr 2015 12:37:23 +0000 (UTC) Received: from elf.torek.net (mail.torek.net [96.90.199.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 403F71450; Fri, 24 Apr 2015 12:37:22 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.9/8.14.9) with ESMTP id t3OCbLH7039665; Fri, 24 Apr 2015 05:37:21 -0700 (PDT) (envelope-from torek@elf.torek.net) Received: (from torek@localhost) by elf.torek.net (8.14.9/8.14.9/Submit) id t3OCbLmd039664; Fri, 24 Apr 2015 05:37:21 -0700 (PDT) (envelope-from torek) Date: Fri, 24 Apr 2015 05:37:21 -0700 (PDT) From: Chris Torek Message-Id: <201504241237.t3OCbLmd039664@elf.torek.net> To: dim@FreeBSD.org Subject: Re: svn commit: r281451 - head/sys/vm Cc: adrian@freebsd.org, dchagin@freebsd.org, scott4long@yahoo.com, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org In-Reply-To: <695B6002-002A-406C-B843-0DCFE24F81BD@FreeBSD.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Fri, 24 Apr 2015 05:37:22 -0700 (PDT) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 12:37:23 -0000 True, it's not actually odd, it's just surprising the first time one comes across it. Also, I goofed in the text: >> With the flexible array, (sizeof(struct uma_cache)) is going to be >> 32 bytes smaller than without it. It's `struct uma_zone` that shrinks by (potentially) more than one would expect. (The uma_cache struct is itself 32 bytes and is not changed, so the args.size value should be the same -- implying that some OTHER "sizeof(struct uma_zone)" is where things are going wrong.) Chris