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. Thanks! Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
