00:27 <derzahl> i have my kernel patched with mglru now but its not turned on

00:29 <derzahl> i patched it with a bunch of stuff and was surprised they both applied cleanly and compiled. my main objective was to compile with -O3 and armv8.2a tuning, and switch to the cacule sceduler

00:30 <derzahl> its been running great and now im trying to see if I can get the fingerprint reader to work

09:02 <arnd> derzahl: -O3 tends to make the kernel behave worse because the aggressive loop unrolling just grows the kernel in places that don't matter. However, if you find a workload for which it matters, we can manually unroll the loop that there

09:04 <arnd> I also wouldn't expect armv8.2 to make much of a difference for the kernel, again if you want to have an armv8.2-only kernel it would be better to optimize the places that do matter, such as using the LSE atomics unconditionally

09:05 <arnd> One optimization that apparently does help is to use link-time-optimizations on the kernel

16:47 <hexdump0815> oh - whitequark irc log is back - a big thanks to whoever is responsible for making it working again

16:50 <robclark> I changed the channel flags back to +M -R .. that seems to be the lesser of evils

16:51 <HdkR> At least then you can flail silently until you realize nickserv failed to authenticate for w/e reason :D

16:52 <HdkR> Looking forward to OFTC gaining support for SASL

20:09 <derzahl> arnd: Thanks for the suggestions. I will check on that. I thought the -O3 problems you stated is no longer true with modern compilers.

20:12 <arnd> derzahl: no, since -O3 tends to make things worse, nobody is using it any more, and we eliminated the Kconfig option for anything other than CONFIG_ARC

20:13 <arnd> so we don't even notice when it breaks

20:18 <derzahl> arnd: I dont think -O3 even enabled -funroll-loops, does it?

20:19 <arnd> this is what the gcc docs say: https://www.irccloud.com/pastebin/tS4GylBO/

20:20 <arnd> most of these are about loop optimization in some form

20:20 <arnd> so no -funroll-loops, but a lot of related options

20:22 <derzahl> yeh, i just ran: gcc -c -Q -O3 --help=optimizers

20:27 <derzahl> I remember reading a discussion on LKML where a dev was suggesting enabling it by default(at least on his particular driver). I think Linus dissented for the sake of caution, But other devs mentioned the loop unrolling problems of the past were solved .

20:27 <derzahl> tried to find it again but cant

20:31 <derzahl> just checked, LSE atomics is enabled

20:32 <derzahl> i have CONFIG_LTO_NONE=y

20:32 <derzahl> so i guess that means its not using LTO?

20:33 <derzahl> Whats your opinion on LLVM vs gcc? Im guessing its not good to use LLVM to compile the kernel on a distro compiled with gcc

20:38 <HdkR> Kernel ABI doesn't care about mixing your compilers like that

20:40 <derzahl> would it make a difference?

20:41 <derzahl> i think I need to use clang to get LTO, right?

20:42 <derzahl> currently Im not given any options for LTO besides "NONE"

20:54 <HdkR> gcc also supports LTO, not sure what is necessary for the kernel to enable the option though :)

20:54 <robclark> using llvm to build kernel and gcc to build userspace is fine

20:57 <derzahl> hmm "make LLVM=1 LLVM_IAS=1 nconfig" gives me the option of thinLTO, but not full LTO. Any idea why?

20:57 <derzahl> does it matter?

21:02 <robclark> no idea, haven't really played with LTO myself

21:06 <HdkR> thinlto is pretty much as good as "fat" lto

21:06 <HdkR> and doesn't use all the ram in the world

21:07 <HdkR> thinlto is clang+lld only, gcc doesn't support that

21:08 <HdkR> I guess gold supports thinlto?

21:08 <derzahl> whats gold?

21:09 <HdkR> Another linker

21:10 <HdkR> https://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html Has a fairly old breakdown with some graphs. Basically the same today :)