On 01/04/2017 06:07 AM, Minchan Kim wrote: > With this, > ./scripts/bloat-o-meter vmlinux.old vmlinux.new.new > add/remove: 1/1 grow/shrink: 0/9 up/down: 1394/-1636 (-242) > function old new delta > isolate_lru_pages - 1394 +1394 > print_fmt_mm_vmscan_lru_shrink_inactive 359 355 -4 > vermagic 64 58 -6 > perf_trace_mm_vmscan_lru_shrink_active 264 256 -8 > trace_raw_output_mm_vmscan_lru_shrink_active 203 193 -10 > trace_event_raw_event_mm_vmscan_lru_shrink_active 241 225 -16 > print_fmt_mm_vmscan_lru_shrink_active 458 426 -32 > trace_event_define_fields_mm_vmscan_lru_shrink_active 384 336 -48 > shrink_inactive_list 1430 1271 -159 > shrink_active_list 1265 1082 -183 > isolate_lru_pages.isra 1170 - -1170 > Total: Before=26268743, After=26268501, chg -0.00% > > We can save 242 bytes. > > If we consider binary size, 424 bytes save. > > #> ls -l vmlinux.old vmlinux.new.new > 194092840 vmlinux.old > 194092416 vmlinux.new.new
Which is roughly 0.0002%. Not that I'm against fighting bloat, but let's not forget that it's not the only factor. For example the following part from above: > isolate_lru_pages - 1394 +1394 > isolate_lru_pages.isra 1170 - -1170 shows that your change has prevented a -fipa-src gcc optimisation, which is "interprocedural scalar replacement of aggregates, removal of unused parameters and replacement of parameters passed by reference by parameters passed by value." Well, I'm no gcc expert :) but it might be that the change is not a simple win-win.
