Date: Thu, 20 Sep 2012 12:03:07 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Dag-Erling Sm??rgrav <des@des.no> Cc: hackers@freebsd.org Subject: Re: fdgrowtable() cleanup Message-ID: <20120920090307.GY37286@deviant.kiev.zoral.com.ua> In-Reply-To: <864nmtn8ap.fsf@ds4.des.no> 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> <864nmtn8ap.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
--36OpTq80o519DUb3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 19, 2012 at 09:04:30PM +0200, Dag-Erling Sm??rgrav wrote: > Konstantin Belousov <kostikbel@gmail.com> writes: > > "Dag-Erling Sm??rgrav" <des@des.no> writes: > > > I assume you mean assignments, not calculations. I trust the compiler > > > to move them to where they are needed - a trivial optimization with S= SA. > > 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. >=20 > 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. Compiler cannot change the semantic of the program regardless of the phase of compilation the change happens at. Compiler that would reorder reads from the global memory across sequential points seems to be not disallowed by c99, but it certainly contradicts to our semantic of the lock releases, which the compiler cannot infer from the non-inlined function calls. Malloc call is the sequential point and does have the release semantic FWIW. >=20 > > > 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. >=20 > 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. Ok. >=20 > 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). >=20 > BTW, I just noticed that there is some dead code in fdgrowtable(): >=20 > nnfiles =3D NDSLOTS(nfd) * NDENTRIES; /* round up */ > if (nnfiles <=3D onfiles) > /* the table is already large enough */ > return; >=20 > /* ... */ >=20 > /* 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; >=20 > Since neither nnflags nor onflags are modified between these two chunks > of code, the condition in the second if will always be true. You mean that new bitmap shall be always allocated, making the nmap =3D NULL assignment not needed ? I agree. It would also make the code in the last if () executed unconditionally. --36OpTq80o519DUb3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBa28sACgkQC3+MBN1Mb4iMvQCgs8ErLCd+u/rdXJlFY62KSEyL b/0AoOh4rMwY2hPpjBfHwu14/zyRA0Re =BFWO -----END PGP SIGNATURE----- --36OpTq80o519DUb3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120920090307.GY37286>