Comment # 10 on bug 1200487 from Mel Gorman

Results show some small improvements for some workloads and at least one
functional failure. The mmtests configuration that failed is
functional-ltp-cve-xfs for the pty03. The other tests were not complete as I
write this as the machine had frozen but will be started shortly. The dmesg for
the failure was

[ 2465.240179] INFO: task pty03:10270 blocked for more than 491 seconds.
[ 2465.240188]       Tainted: G            E     5.18.4-lto-enabled #1
[ 2465.240192] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 2465.240195] task:pty03           state:D stack:    0 pid:10270 ppid:     1
flags:0x00004004
[ 2465.240204] Call Trace:
[ 2465.240207]  <TASK>
[ 2465.240212]  __schedule+0x344/0x12e0
[ 2465.240231]  ? number+0x349/0x400
[ 2465.240242]  schedule+0x5b/0xd0
[ 2465.240249]  schedule_timeout+0x9f/0xd0
[ 2465.240260]  wait_for_completion+0x7d/0x130
[ 2465.240267]  devtmpfs_delete_node+0xc7/0x100
[ 2465.240276]  ? kernfs_put+0x107/0x1c0
[ 2465.240290]  device_del+0x408/0x4f0
[ 2465.240304]  ? class_find_device+0xde/0x1a0
[ 2465.240313]  device_unregister+0xe/0x60
[ 2465.240320]  tty_unregister_device+0x5c/0xc0
[ 2465.240335]  gsmld_close+0x41/0xc0 [n_gsm
3758e2ed62c48c2b7e0f63935531528aa58bfb68]
[ 2465.240348]  tty_ldisc_hangup+0x131/0x240
[ 2465.240358]  __tty_hangup+0x1f3/0x370
[ 2465.240366]  tty_ioctl+0x74e/0x9d0
[ 2465.240372]  ? exit_to_user_mode_prepare+0x181/0x1f0
[ 2465.240386]  ? syscall_exit_to_user_mode+0x17/0x40
[ 2465.240399]  ? do_syscall_64+0x67/0x80
[ 2465.240405]  ? __x64_sys_ioctl+0xc7/0xe0
[ 2465.240413]  __x64_sys_ioctl+0xaa/0xe0
[ 2465.240418]  do_syscall_64+0x5b/0x80
[ 2465.240423]  ? syscall_exit_to_user_mode+0x17/0x40
[ 2465.240430]  ? do_syscall_64+0x67/0x80
[ 2465.240434]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 2465.240441] RIP: 0033:0x7feb93515c47
[ 2465.240447] RSP: 002b:00007fffd4d00938 EFLAGS: 00000246 ORIG_RAX:
0000000000000010
[ 2465.240453] RAX: ffffffffffffffda RBX: 0000000000620670 RCX:
00007feb93515c47
[ 2465.240457] RDX: 0000000000000000 RSI: 0000000000005437 RDI:
0000000000000008
[ 2465.240461] RBP: 0000000000000009 R08: 00000005deece66d R09:
000000000040dde0
[ 2465.240464] R10: 00007fffd4ddf170 R11: 0000000000000246 R12:
0000000000000008
[ 2465.240467] R13: 0000000000000000 R14: 0000000000000000 R15:
0000000000000008
[ 2465.240472]  </TASK>

It never recovered.

The performance results are at

http://laplace.suse.de/marvin-manual/mgorman-lto/dashboard.html
http://laplace.suse.de/marvin-manual/mgorman-lto-full/dashboard.html

mgorman-lto compares disabled vs enabled where as mgorman-lto-full has a
baseline without any LTO patches.

The biggest curiosity with the baseline vs disabled was tbench which showed a
large gain where none was expected and netperf which showed a loss where none
was expected.

For disabled vs enabled, there was a smallish 1-2% gain for hackbench.
hackbench is not a very good benchmark but it is kernel intensive. The small
gain is nice but there are other ways this could be improved more (e.g. better
cutoff on idle CPU search depths being worked on upstream).

Netperf showed a decent gain in some cases but given that baseline vs disabled
showed an unexpected loss, the overall gain is much smaller and may be a
coincidental code layout difference.

Otherwise it was marginal differences.