From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 19 19:04:33 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFBE01065680 for ; Wed, 19 Sep 2012 19:04:33 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 80C4B8FC0A for ; Wed, 19 Sep 2012 19:04:33 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 439406023; Wed, 19 Sep 2012 21:04:32 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id E6858860C; Wed, 19 Sep 2012 21:04:31 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Konstantin Belousov References: <86wqzr8hbk.fsf@ds4.des.no> <20120919061005.GR37286@deviant.kiev.zoral.com.ua> <86lig6map1.fsf@ds4.des.no> <20120919175354.GV37286@deviant.kiev.zoral.com.ua> Date: Wed, 19 Sep 2012 21:04:30 +0200 In-Reply-To: <20120919175354.GV37286@deviant.kiev.zoral.com.ua> (Konstantin Belousov's message of "Wed, 19 Sep 2012 20:53:54 +0300") Message-ID: <864nmtn8ap.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: fdgrowtable() cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 19:04:33 -0000 Konstantin Belousov writes: > "Dag-Erling Sm=C3=B8rgrav" writes: > > I assume you mean assignments, not calculations. I trust the compiler > > to move them to where they are needed - a trivial optimization with SSA. > It is a dereference before the assignment, so I perceive it as the > calculation. No, I do not think that compiler can move the dereference, > because there are many sequential points between the calculation and > use of the result. Sequence points are a language feature and are only meaningful in the translation phase. Once the code is in SSA form or some other equivalent intermediate representation, the compiler can see that the variables are only used in one specific case and move the assignments inside that block. In fact, it will probably optimize them away, because they are completely unnecessary - I added them solely for readability after Niclas called my attention to the fact that it is almost impossible to understand fdgrowtable() at a first reading. > > Correct, thanks for pointing it out. The easiest solution is to place > > the struct freetable between the file array and the flag array. > As I know, for all ABIs FreeBSD run on, the structure alignment is the > alignment of the most requiring member. You would introduce very tacit > dependency between struct file and struct freetable. The existing code *already* places the struct freetable immediately after the struct file array. What I'm proposing now is to leave the struct freetable where it was but move the fileflags array so they don't overlap. The fileflags array is actually a char[] and has no alignment requirement. Memory usage will not increase, because the code already allocates additional space for the struct freetable to make sure it will fit even if onfiles < sizeof(struct freetable). BTW, I just noticed that there is some dead code in fdgrowtable(): nnfiles =3D NDSLOTS(nfd) * NDENTRIES; /* round up */ if (nnfiles <=3D onfiles) /* the table is already large enough */ return; /* ... */ /* allocate new bitmaps if necessary */ if (NDSLOTS(nnfiles) > NDSLOTS(onfiles)) nmap =3D malloc(NDSLOTS(nnfiles) * NDSLOTSIZE, M_FILEDESC, M_ZERO | M_WAITOK); else nmap =3D NULL; Since neither nnflags nor onflags are modified between these two chunks of code, the condition in the second if will always be true. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no