On 15 July 2016 at 11:51, Laszlo Ersek <[email protected]> wrote: > On 07/15/16 11:25, Ard Biesheuvel wrote: >> On 15 July 2016 at 11:06, Laszlo Ersek <[email protected]> wrote: > >>> And, to our collective relief, this means that there should be no >>> problem with this series. :) I think I can add my Tested-by: >>> >>> Tested-by: Laszlo Ersek <[email protected]> >>> >> >> Thanks a lot! >> >> I do have another question, though. Looking at your logs, I found the >> following results for the sizes >> >> GCC48 before: >> >> SECFV [11%Full] 212992 total, 25392 used, 187600 free >> FVMAIN_COMPACT [63%Full] 1753088 total, 1113976 used, 639112 free >> DXEFV [56%Full] 10485760 total, 5970624 used, 4515136 free >> PEIFV [21%Full] 917504 total, 200616 used, 716888 free >> >> GCC48 after: >> >> SECFV [7%Full] 212992 total, 15728 used, 197264 free >> FVMAIN_COMPACT [65%Full] 1753088 total, 1145808 used, 607280 free >> DXEFV [39%Full] 10485760 total, 4148384 used, 6337376 free >> PEIFV [14%Full] 917504 total, 131208 used, 786296 free >> >> >> GCC49 before: >> >> SECFV [12%Full] 212992 total, 25616 used, 187376 free >> FVMAIN_COMPACT [64%Full] 1753088 total, 1122760 used, 630328 free >> DXEFV [58%Full] 10485760 total, 6106048 used, 4379712 free >> PEIFV [22%Full] 917504 total, 205992 used, 711512 free >> >> GCC49 after: >> >> SECFV [7%Full] 212992 total, 15824 used, 197168 free >> FVMAIN_COMPACT [66%Full] 1753088 total, 1166952 used, 586136 free >> DXEFV [40%Full] 10485760 total, 4225728 used, 6260032 free >> PEIFV [14%Full] 917504 total, 133672 used, 783832 free >> >> So DXEFV is substantially smaller, but FVMAIN_COMPACT ends up slightly >> bigger. Which one do we care about mostly? I would assume >> FVMAIN_COMPACT, since that translates into flash footprint directly. > > Correct. > > DXEFV is less relevant, but not irrelevant. We've been increasing its > allotted size in the FDF file(s) over time, cramming more and more DXE > phase stuff into OVMF. Its size does have an impact on guest memory > availability, when the SMM driver stack is built in, and S3 is enabled > on the QEMU command line. (Under these circumstances DXEFV's location is > covered as AcpiNVS. Not optimal, but that's what we have.) > > So, in practice, shrinking DXEFV is useful as well. > > FVMAIN_COMPACT is what ultimately determines the flash chip's size. > We've never had to change that (after a historical bump from 1MB to 2MB, > speaking unified flash terms -- for OVMF_CODE.fd, the bump means > 1MB-128KB --> 2MB-128KB). If we have to increase OVMF_CODE.fd, that will > be visible on the host filesystem, and might present compatibility > problems for existing VMs after their next boot. (I hope not, but I've > never actually tested this scenario.) > > Mike mentioned elsewhere in this thread that he measured the utility of > new build flags on the change in compressed size. > > I guess it just tells us that TianoCompress performs incredibly well :) > >> So I did a quick test, comparing O0 / O1 / O2 on GCC48, and it seems >> the sweet spot is O1 (due to lack of support for Os in older GCCs) >> >> -O0 >> >> SECFV [11%Full] 212992 total, 23536 used, 189456 free >> FVMAIN_COMPACT [58%Full] 1753088 total, 1016816 used, 736272 free >> DXEFV [47%Full] 10485760 total, 4978656 used, 5507104 free >> PEIFV [14%Full] 917504 total, 133328 used, 784176 free >> >> -O1 >> >> SECFV [6%Full] 212992 total, 14768 used, 198224 free >> FVMAIN_COMPACT [58%Full] 1753088 total, 1017856 used, 735232 free >> DXEFV [37%Full] 10485760 total, 3907648 used, 6578112 free >> PEIFV [10%Full] 917504 total, 95696 used, 821808 free >> >> -O2 >> >> SECFV [7%Full] 212992 total, 15728 used, 197264 free >> FVMAIN_COMPACT [63%Full] 1753088 total, 1111144 used, 641944 free >> DXEFV [38%Full] 10485760 total, 4029984 used, 6455776 free >> PEIFV [10%Full] 917504 total, 100400 used, 817104 free > > Huh, very interesting. -O1 vs. -O2 produce almost identically sized > PEIFV and DXEFV (both optimization settings beating -O0 of course), but > -O2 does something that makes the compression deteriorate, even to the > point where FVMAIN_COMPACT ends up larger than with -O0! > > More agressive unrolling / inlining with -O2 perhaps? > > And, the effect of -O1 seems to be: practically unchanged FVMAIN_COMPACT > size, relative to -O0 (it's negligibly larger than with -O0 I guess), > and significantly smaller DXEFV and PEIFV usage. > > -O1 seems useful. Assuming that the "negligible" size increase in > FVMAIN_COMPACT, relative to -O0, remains negligible in the long term. :) > >> Anyway, thanks again for your time and effort in testing this, much >> appreciated. > > No, thank you for doing this; I've always been intrigued by the > optimization possibilities for OVMF. What I'd be most interested in is > enabling optimization (saving space) for -b DEBUG -- I don't do source > level debugging, but I want the debug messages and the ASSERT()s. Saving > space with those compiled in would be superb -- I guess that's where the > savings would really shine. >
Doing the same build for DEBUG gives me -O0 SECFV [20%Full] 212992 total, 44464 used, 168528 free FVMAIN_COMPACT [75%Full] 1753088 total, 1326592 used, 426496 free DXEFV [67%Full] 10485760 total, 7077696 used, 3408064 free PEIFV [28%Full] 917504 total, 257200 used, 660304 free -O1 SECFV [16%Full] 212992 total, 35248 used, 177744 free FVMAIN_COMPACT [76%Full] 1753088 total, 1339592 used, 413496 free DXEFV [56%Full] 10485760 total, 5933120 used, 4552640 free PEIFV [23%Full] 917504 total, 216240 used, 701264 free -O2 SECFV [17%Full] 212992 total, 36688 used, 176304 free FVMAIN_COMPACT [83%Full] 1753088 total, 1469904 used, 283184 free DXEFV [58%Full] 10485760 total, 6157440 used, 4328320 free PEIFV [24%Full] 917504 total, 227408 used, 690096 free which paints roughly the same picture: much smaller binaries, but O2 is worse than O0/O1 after compression. Another thing to take into account is that DXE code size translates directly into RuntimeServicesCode memory footprint of DXE_RUNTIME_DRIVER modules, although I am not sure if that has ever been a source of concern. -- Ard. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
