Linus is NOT Allowing this in the Linux Kernel..

[@SavvyNik]

Do you enjoy a little kernel lore?

[@apIthletIcc]

I would vote to cover more of these little back and forths. It is purely entertainment for me but I feel like it would be a good thing for more programmers to see even if they aren't kernel specific.

[@SavvyNik]

Love the feedback

[@guilherme5094]

Yes!

[@johnbowles4754]

Absolutely, I enjoy listening to your views 👍😎

[@scarletevans4474]

I think it's my first video of yours and really enjoyed it :-) Time to learn more!

[@GuzikPL4]

CPUID bits are beautifully simple, no need for that V1, V2 and so on garbage

[@vilian9185]

is good for high lever things i guess, like distros switching to v2 or v3, or maybe high level languages too, but in the kernel i agree it don't make sense

[@valenrn8657]

Redhat and SUSE say Hi.

[@ytechnology]

Way back I wrote apps for Palm Handhelds. Those devices came in many models and various capabilities, from extra buttons to screen rotation. Palm's advice then is similar to Linus' thoughts now: query the device flags to see what features are available rather than just determining the device model. Using v1, v2, v3 abstracts away too much information, and applying a little history -- even from tangential fields -- makes us better developers.

[@mikespangler98]

Applications should check for instructions they need on startup and put up an error message. I got caught by an app that wanted an AVX instruction but the old Xeon doesn't support that. The app bombed out leaving me figure out why. A simple dialog "Your CPU does not support the AVX instructions that this program requires." would have been quite helpful.

[@valenrn8657]

$3.4 billion revenue RedHat releases X86-64 v3 RHEL 10 distro. Old Xeon wouldn't matter for large corporates.

[@AndersJackson]

@@valenrn8657 and why do you think that will make Linus change his thought on this? Stop posting this non information that isn't relevant to this. The "solution" with naming convention instead of set of bits for each feature (CPUID) will not solve anything, it will only make it WAY more complicated. IF they want to change this, they are welcome to fork Linux, and call it something else. Linus will not let stupid code and features into the kernel code. You probably have no clue about the technical problem, as you continue posting this.

[@AndersJackson]

Yes, they should and they usually do, when being properly built. There are always people that doesn't know or think about this. They think a notice in some README.txt or marketing document somewhere is enough. It isn't. So if a feature is there, they use it in a optimized version of a library. If not, they use a non optimized version of the library. Selected when the program starts.

[@dycedargselderbrother5353]

CPUID has been in continuous use since the 1990s. Certain feature sets, such as AVX[2|512], are not reliably available on a temporal level. That is, they come and go depending on product tier and market segment. Throw in both AMD and Intel and now "versions" really have no meaning.

[@lsatenstein]

So, do you agree with Linus?

[@dycedargselderbrother5353]

@@lsatenstein Yes, I do.

[@valenrn8657]

$3.4 billion revenue Red Hat and $1 billion revenue SUSE says Hi. Linux Foundation is just $177 million in revenue with fewer big support contracts when compared to Red Hat and SuSE.

[@AndersJackson]

@@valenrn8657 and so what? If they want to throw this into Linux, they have to fork it and name it something else and have someone else manage the source. Linus will not allow this bull into the kernel, when there ALREADY are a better AND working use case for selection different instructions depending if they exist or not. That is, the CPUID register/instructions that make the CPU tell us what instructions are purported, not the compiler guessing. And probably guessing wrong.

[@t1m3f0x]

If something isn't "reliably available" then essentially even if your CPU supports it, the feature still doesn't exist unless you compile your own software. V1 V2 etc exist because there's too many possible CPUID variations to provide binaries for all of them. CPUID is for building from source, V1 V2 is for distributing binaries.

[@scottdrake5159]

I'm with Linus on this one. It is a simplification the adds complexity. The still unclear issue of mtune+march on gcc demonstrates the problem. The "generic" thing is kind of a retcon. (Specify both if you want a "native" build with all cpu extenstions enabled.) It's so complicated to express this with code (and so error-prone).

[@pskocik]

The CPUID explanation is bad. There's no CPUID register. There's a CPUID *instruction* and it reads feature bit info into the EAX,EBX,ECX, and EDX registers. Those registers are in all 32 bit x86 archs, AFAIK, and predate the introduction of the CPUID instruction. It makes no sense for CPUID to want to load featureset bits for registers that are always needed by it.

[@AndersJackson]

Correct, but doesn't change anything in the argumentation of this arbitrary instruction sets that was suggested. That isn't even supported by Intel nor AMD. If it was, there would have been instructions or registers for it.

[@Dr-Zed]

Linus once again shows that he knows what he's doing and makes based decisions.

[@t1m3f0x]

The problem with V1 V2 V3 V4 is CPU makers don't use it. What we need is for the CPU makers to adopt a standardized system with user friendly market names. V1 V2 etc exist because the CPU makers failed in their marketing. It was created because CPU makers weren't slapping standardized easy to use market names on everything, and people wanted a system designed to make things easy for them when compiling.

[@JonathanFraser-i7h]

The kernel is no place for marketing material. Does CPU A support instruction B is all that needs to be known. You can have a config that is ENABLE_AVX512_OPT or something but even that is a bit silly because it should be set by the compilers CFLAGS.

[@t1m3f0x]

@@JonathanFraser-i7h I'm just saying that people want CPUs to have all that stuff reduced down to a handful of skews with user friendly names. But seeing as V1 V2 etc were made, would it kill Intel and AMD to just slap the applicable Vwhatever on the spec sheet.🙄

[@binaryblade2]

​@@t1m3f0xproblem is (as indicated in the video) it simplifies things to the point of being wrong. V4 is not a strict superset of v3, etc. Keep the marketing bull where it belongs. If you aren't knowledgeable enough to understand some boolean flags, you aren't knowledgeable enough to be screwing with it anyway.

[@t1m3f0x]

​@@binaryblade2 Well that's why they should have made the system themselves, then they could have given them better names. Point is unless they make a replacement system that's official it's not going away.

[@binaryblade2]

@t1m3f0x only morons need things spoon fed to them. Making important technical decisions based on the ability to establish marketing terminology is probably the worst take I've seen.

[@CalgarGTX]

I'm really curious to see what happens to the linux kernel when the main guy in charge unalives/retires. Considering what a fragmented cobbled together mess of an ecosystem it already is, and how clueless devs are already trying to push things in the kernel that are fundamentally broken like this exemple right here.

[@lsatenstein]

@@CalgarGTX Russia is forking Linux and will provide an alternative Linux for non American aligned populations So much for removing the dozen Linux developers.

[@sergrojGrayFace]

V1, V2, ... make sense when you need to support different instruction sets and instead of creating a ton of variations of your executable for every possible CPUID variation you make variants for these V* slices of features.

[@AndersJackson]

OR you check what features you need, and check them in the beginning of the code. Then you just select the version that is supported. Works as well as Linus suggests. As I would have said if I was Linus. "Finns inget behov av påphittade nivåer som inte finns i från Intel (eller AMD), eftersom samma information redan finns i CPUID". In the language of Linus and his parents.

[@t1m3f0x]

@@AndersJackson If a dev has a choice between making two versions of an executable or ten versions of an executable with an installer that will handle figuring out which one to install, it's unrealistic to expect them do the later. CPUID is just too granular to be useful if you're building something for distribution, unless you know what CPU it's going to be running on you can ether use V1 V2 etc or only support the baseline features.

[@tacokoneko]

@@t1m3f0x open a copy of the Glibc source code right now and go to the file "glibc/sysdeps/x86_64/multiarch/ifunc-memcmp.h" in there you will find a 20 line long example of AVX512 runtime dynamic dispatch (NOT fat binary) that only activates AVX512 code if the current CPU the compiled binary is running on supports AVX512. that is what linus expects every good programmer to do. there is a skill barrier to that but it means linus is implying that software that doesn't do that, that nobody can fix to do that, must be bad code that isn't his responsibility.

[@jaimeduncan6167]

He is correct. The language is not PC but he is doing better.

[@cheako91155]

I think hashing and buckets is useful, do we need 32 thousand optimization levels for building the kernel or is 4 enough?

[@gast128]

Idea could work as simplification of the dozen features. Especially if different kernels could be build and loaded depending on the present processor capabilities. Then again not sure if SSE2 / AVX register may be used in kernel mode.

[@AndersJackson]

No. You don't know the problem. That is why you don't see that it is a bad solution. Sorry.

[@Youssef-zy8hk]

All this linux drama finna make me switch to freebsd

[@pfitz4881]

🤣 Just stay out of the drama

[@Myname-l3h]

These dramas were always there. Why would you even start using Linux in the first place?

[@AnnCatsanndra]

​@@Myname-l3hOne can eat a burger without knowing the opinions of the slaughterhouse, the shipping company, the maker of the freezers, the cooks who prepared it , the guy who wrapped it, the cashier... So "Why even start using (Linux)" and "These opinions about (Linux) were always here" are not as tightly coupled for end users as you might assume.

[@hiru92]

@@Myname-l3h joking

[@autohmae]

There is no drama, this is just the normal technical discussions. It's just that this is the biggest open source/free software project in the world and thus gets attention. These same kind of technical discussions happen at Microsoft or BSD or any large software project.

[@saultube44]

Precision is the goal, hence there are specific ID Instructions in CPUs to ID themselves and their capabilities, this way we know for sure what we're dealing with; some generic subsets is just meaningless and useless info, just like padding data structures

[@darknetworld]

Wow naming v1-v3 that make it harder for dev. It need clear meaning instead of non sense naming. What if down the line someone want to change it again again. I hope this person is not making obscure for being hacked or exploit.

[@kreuner11]

This definitely won't exploit anything but it's dumb

[@valenrn8657]

SUSE and Red Hat support X86-64 levels and they have large support contracts. Linux Foundation ($177 million) is a small revenue company compared to Red Hat ($3.4 billion, IBM's Linux biz unit) and SUSE ($1 billion)

[@robertanderson5092]

Do cpus really support eax but not the others?

[@pskocik]

No. The example was wrong. The CPUID instruction loads the featureset bits into all those registers. The regs are always there. There's no featureset bits for them.

[@SXZ-dev]

Question do the microarchitectures really vary that much? Do you really have processors with support for SSE 4.2 but not SSE 4.1? Or Processors with AVX2 but no AVX 1 support? I don't know of any... the new microarchitectures tend to just add stuff on top of what was already there which is likely where the V1, V2 and V3 simplification came from as there are likely only a handful of real variations Now, if there is an official standard i don't see why you shouldn't use it, but Linus is being overly agressive as usual

[@dycedargselderbrother5353]

AVX-512 is like this. It's more a family of implementations than a single thing. Some features have been dropped as new ones were added and some come and go between product lines. You can still make reasonable guesses by architecture level rather than reading CPUID, but it's not clear why that is a good idea when a definitive method already exists, i.e. CPUID. Also, something like, say, Tiger Lake supports AVX-512 but the Celerons and Pentiums don't.

[@valenrn8657]

AVX 1 is as old as Ivybridge, Jaguar, and Bulldozer. These old CPUs wouldn't matter for corporate Red Hat or SuSE.

[@AndersJackson]

@@valenrn8657 again. that is NOT an issue for Linus Torvalds. As an example. I ranted on a list where he was that Linux would drop support of booting OLD SGI PC computers, which I happen to run (for some software I could move away to more modern hardware, but had not). I got an email from Linus (in Swedish, as we both are native speakers) where he asked if I really needed that support. Because if I did, he would let it be in. I said thanks for asking and apologized for taking up his time. But I should really get rid of those computers. So you are basically wrong. Linus will NOT drop support for older CPU:s without a reason. A real TECHNICAL reason.

[@SeekingTheLoveThatGodMeans7648]

This wouldn't stop anyone from creating kernels for each of these versions by translating them to CPUID requirements, right?

[@StephenMcGregor1986]

"Red Hat already moved recently in their 9.5 release to be x86-64-v3 as default, which generally brings around 5 to 10% performance depending on the application." "This model is used in many places, not only in glibc. For example, in Vulkan new extensions are added every week and then at some point in time a subset of new extensions is marked as mandatory and labelled as a new Vulkan version. So, instead of saying the kernel requires [a list of 354 x86 instuctions] you can simplify and say "our baseline is x86_v3"."

[@edelzocker8169]

Or lowers performance 5 to 10% depending on what you are doing...

[@kreuner11]

​@@edelzocker8169 no it will just not use the extra optimizations if not available

[@kreuner11]

Until Intel makes this official with collaboration with amd then let's not use this unreliable metric. Even then you still need cpuid to check for support for more exotic features like avx-512

[@dantenotavailable]

Comparing RedHat (a userspace distribution) and Vulkan (a literal standard) to the state of x86_64 is like comparing Apples and Oranges to Uranium.

[@edelzocker8169]

@@dantenotavailable Tasty...

[@Yamahog]

Linus is always correct. That Binary example you gave should be the standard...... Set " Read CPU ID capabilities = on.", for all CPU's and then let the CPU tell the kernel what's available code wise ,and enable them, and be done with that BS architectural side -lane

[@valenrn8657]

That's wasting clock cycles.

[@SeekingTheLoveThatGodMeans7648]

@@valenrn8657 The kernel needs to only ask once, when it starts. If it is known that for optimization sake a particular CPUID feature is required because there is no alternative conditional code in the kernel that requires checking the saved CPUID, then that kernel should know about the required CPUID feature(s) and check for it and issue an error message and quit if necessary, at boot time.

[@valenrn8657]

@@SeekingTheLoveThatGodMeans7648 RHEL, SuSE, AMD, and Intel created X86-64 levels in 2020. Linus wasn't invited. RHEL ($3.5 billion) and SuSE ($1 billion) large-scale support contracts. Linux Foundation only has $177 million.

[@Hofer2304]

Is it possible to test which instructions a CPU has?

[@dycedargselderbrother5353]

Yeah, CPUID. It's a command line program in Linux and you can use CPU-Z in Windows.

[@Hofer2304]

@dycedargselderbrother5353 The CPUID instructien is useful to test which instructions a CPU should have, but how do I know the CPU isn't lying?

[@dantenotavailable]

​@@Hofer2304 Because "Trusting Trust". Sure you could write some binary snippets (because if you're that paranoid then it has to be raw binary, the compiler might be equally lying to you) to confirm that the CPU gives correct outputs for known inputs. And then you'd probably be best to have a large sample of known input/output pairs that you select randomly because maybe the CPU is specifically rigged to answer correctly on the inputs you've given it but then gives the wrong answer on other requests. And maybe you should interject tests while in the middle of running your code because "the Volkswagen emissions scandal" is a thing we know about and you can never be entirely sure that they're not better at detecting your test environment than you are at hiding it. And I hope you've got a good trust fund because no-one is going to pay you to not release software like that. Alternatively, you could just code to the abstraction assuming that they got it right and then in those inevitable cases where the engineering goes wrong (lookin at you Intel gen 13 and 14), that's what RMA is for.

[@dycedargselderbrother5353]

@@Hofer2304 I'm not aware of the behavior where CPUs claim to have features that they don't. The closest things I can think of are architectural bugs, like the math bug with the original Pentium or the broken VT-d support in the initial Sandy Bridge-E launch. But in these cases you need to work around specific processor steppings with some sort of exemption list. It's been a long time since I've built a Linux kernel but those sorts of exemptions were built into the kernel config since the start. I assume they're still there.

[@rchltmedia]

there is no x86-64 V1, V2, V3 etc. this is not ARM.

[@valenrn8657]

You missed the year 2020 collaboration.

[@MrBox4soumendu]

thanks buddy...

[@Valk-Kilmer]

Leenus? What?

[@ikarm]

It is time to fork the kernel.

[@SavvyNik]

lol sound the alarms

[@realshaoran4514]

Please do that. Nobody is stopping you forking linux.

[@WERTBON]

@@realshaoran4514 In fact, there are thousands of Linux forks, there are probably more forks than active maintainers in upstream

[@ikarm]

@@WERTBON There is only one Kernel. There are many "distributions" of Linux, but they all use the same Kernel.

[@absalomdraconis]

​@@ikarm: Most development is done in forks, not the mainline kernel.

[@pfitz4881]

I have to agree this only adds confusion. Go get em Linus (LYnus)

[@__Brandon__]

GNU+LeeNus

[@marbens]

This video adds confusion. People think he's talking about the microarchitecture itself and not the naming.

[@StephenMcGregor1986]

Ok Linus and all HOW should this be differently handled via a "cpuid featureset", does this querying happen and then optimizations are applied based upon this information acquired automatically?

[@SavvyNik]

Yeah I know some distros use the Vx schema for optimizations but you could also query a CPUID register based on the hardware config. It’s a good question

[@WERTBON]

The Kernel could potentially read the cpuid values at runtime and choose a branch with the SSE/AVX instrutions when the appropriate bits are set. If you then want to only have the optimized versions you can build only them basically. The versions are really just saying which major architecture feature the target has, but with a optimized kernel you would want to fine grain beyond that, so not from generic to v2 for SSE2 instructions, but rather explicitly saying "My target has SSE2, I wanna use that". v2, v3, v4 etc. is just not very clear what that actually means, where you can just put "SSE2 Support" (and then SSE2-only) into the Architecture Settings or kernel hacking for those who are interested. Probably not even close to how it's actually made in the kernel, but some JIT compilers actually do it this way mostly at runtime, tho.

[@valenrn8657]

In 2020, through a collaboration between AMD, Intel, Red Hat, and SUSE, three microarchitecture levels (or feature levels) on top of the x86-64 baseline were defined: x86-64-v2, x86-64-v3, and x86-64-v4. Linus is ignorant.

[@kreuner11]

3:48 glibc, not GLib, a very different thing

[@ContemplativeCat]

I love Linus.

[@pfitz4881]

I like him a lot better than Lenus

[@ordinarryalien]

@@pfitz4881 His evil twin? Yeah, I don't like him either.

[@Franchise9920]

"Leenus" It's so disturbing to the ear.

[@SonOfRamenEgg]

I think that is the correct pronunciation though.

[@fontenbleau]

He is completely lost his mind, everyone already witnessed his paranoia signs (conspiracies rumored some compromising materials against him in NSA).

[@v2ike6udik]

if you´d only knew how serious he was. i have problem with ppl who do not have "paranoia" aka being in contact with reality.

[@apIthletIcc]

dang 7min ago sweet

[@SavvyNik]

On top of it haha

[@零云-u7e]

I thought the v stuff is something Intel pushed because AMD phased in new instructions across cpus. It wasn't enforced modular inclusive thing. Try writing code to identify v3/v4. After CachyOS recompiles binaries for their v4 repo, I wanted to know things. It's annoying and weird, and Torvalds got mad at Intel for adding more esoteric instructions most will not use. They get introduced as hardware tweaks/optimized things, and worth arguing about relevance, versus KISS.

[@valenrn8657]

X86-64 levels were collaborations done by Redhat, SUSE, AMD, and Intel in 2020. It's just Linus wasn't included in the Linux Enterprise collaborations.

[@Sunrise-d819i2]

cachy OS proves linus wrong and i'm full disagree with this statement from him too. he is actually holding back linux once again

[@marbens]

He's not talking about the optimizations. He's talking about the naming scheme.

[@dantenotavailable]

CachyOS proving that Linus is entirely right by showing they can implement their preferred scheme without having to fork Linux.

[@fontenbleau]

Are he even scientist or researcher using such language publicly? Asperger syndr? When you use low class argo in disputes that's working against you, usually.

[@richardbennett4365]

CachyOS very much cares about v2, v3, and v4, because it optinizes the kernel and all packages so they fly!!!

[@StephenMcGregor1986]

i've seen the benchmarks and cachy is quick

[@midimax2998]

I wonder how they figure out what vX they need for a certain CPU. My guess would be they have to read the CPUID bits and interpret that.

[@Sunrise-d819i2]

@@midimax2998 the cpu tells the kernel what it supports by the bios when the kernel reads the hardware info.

[@richardbennett4365]

LINE-us.

[@ArturdeSousaRocha]

The "leenus" pronunciation is the original one, regardless of Americans' inability to speak foreign languages.

[@dantenotavailable]

... is not how you pronounce "Linus" when you're speaking in Swedish, which his mother was.

[@richardbennett4365]

@@ArturdeSousaRocha Good! Excellent. Ever hear how the French butcher the pronunciation of North American names and other English words. It is a world phenomenon, not just a USA thing! Good, man! You are so excellently correct.

[@richardbennett4365]

@@dantenotavailable Okay, Sir. Let's ask Mr Torvalds how he pronounces his name and use that pronunciation. It will be the most correct version, no?

[@dantenotavailable]

@@richardbennett4365 Out of interest, did you search KZbin for that? Because there's two basic versions of video that answer that. One where he explicitly uses "Lee-nas" (and only that). And another (an excert from an interview) where he states he uses subtle variants of "Lee-nas" in Swedish and Finnish and "LINE-us" in English but he doesn't really care how people pronounce it. So in other words, I'm entirely correct that "LINE-us" is not the way his mother would have pronounced it even if he does use it around English speakers and he would likely think someone is weird if they were correcting someone else who was saying it more or less the way his mother would have.

[@soberconversations]

How clickbaity 🥱

[@awdsqe123]

It perfectly describes what's in the video ;)

[@javabeanz8549]

That's great that the CPUs have those bits, but what if you are compiling for a different model of CPU? Then checking the bits in the CPU that's used for compilation is not valid. Not that I disagree with Linus, but how do you denote the CPU that you are compiling for in the options?

[@ShenLong991]

standards... they exists long before someone thought about calling different levels of implementation v1, v2, v3. You can even use x86 without all features and use plain old 8bit Instructions. But nobody wants it.