two thumbs and now building nvidia drivers by hand. waste of my opposable thumbs
Discussion
Loading...
@hipsterelectron opposable thumbs were a mistake
👍🪓🐔
👍🪓🐔
@lkundrak we lost everything when we lost the toes of our ape form
this time it failed for a good reason but i'm about to make it fail for horrifyingly nihilistic reasons again
OMG GUESS WHO HAS TWO THUMBS AND NEEDS TO COMPILE THEIR KERNEL FUCKING AGAIN AFTER UPDATING GCC
i'm about to literally fix all of this for everyone but i need to fix this to do everything else
the problem is never ever gcc's fault. the problem is your fucking tooling
sometimes the problem is gcc's fault
@hipsterelectronhttps://tech.lgbt/@somebody/114492884140168697 if you knew the horrors that lurk within GCC you would howl with rage and understand immediately (a fraction of) why this one is actually replacing every single thing down to the last copper supplier (ea nasir joke) (laugh track)
for those keeping track at home that will make 4 full compiles of the beautiful collaboration that interfaces with our hardware
~152 more replies (not shown)
i've decided to set the scheduler strategy to CONFIG_PREEMPT_VOLUNTARY over the linux-zen default of CONFIG_PREEMPT because this laptop has obnoxious specs and they describe CONFIG_PREEMPT as being like for embedded systems (and laptops) whereas CONFIG_PREEMPT_VOLUNTARY is singly characterized as for desktops and i have this thing plugged in 99% of the time
they are pretty clear in the docs for each of these choices why this can't be a dynamic setting because it's about compiling in explicit pre-emption points. kind of an interesting result for such a dynamic process like a scheduler
oh wow but you can change it on the kernel command line and they so it's a very small increase in code. compilers are amazing
i kinda wanna try LTOing this just to see if it will crash my system somehow
i think i'm gonna turn off things like profiling which i don't need right now
kexec is so cool lol
oh hell yes missed CONFIG_SCHED_AUTOGROUP before. linux very much does try to separate build jobs from desktop applications
CONFIG_RCU_NOCB_CPU has a tantalizing description of reducing jitter at the cost of greater context switching. with so many of these switches they really try very hard to make it clear there is no clear right answer (or presumably it wouldn't be config in the first place)
lmao
Say Y here if you hate IPIs.
Say N here if you hate read-side memory barriers.
this is a safe space!!!! we run on spite here!!!!
i delved into the RCU configuration and read some of the great docs and i changed absolutely nothing in the config but had a great time
DAMN! just learned about /proc/pressure. very VERY useful. cargo should be aware of this; maybe my pants could be. i wonder if the make jobserver uses this if available for -j?
i'm gonna enable LTO and then immediately regret it and cancel. or even worse i won't regret it until it's too late. i wanna see what a real fucked up LTO looks like even though i know the only people who run with that option are like google with massive 200-cpu servers
i ABSOLUTELY know this to be true because you literally can't set it in menuconfig and the only supported value is clang's ThinLTO. will mark as TODO to try enabling LTO with gcc and make jobserver
kinda funny about why the status quo is like this. google benefits from the clout saying "yeah yeah yeah we LTO the KERMEL we are FUTURW" regardless of the performance bc as you recall google does not care about computer performance. whereas presumably if gcc lto was not actually useful it wouldn't be worth anyone's time to plumb it into the kernel makefiles
we are now at the drivers/
bonfire.cafe
A space for Bonfire maintainers and contributors to communicate
Automatic federation enabled