'KVM Chainsaw' Expected to Hit Linux 7.3 For Dealing with 'God Data Structure' (phoronix.com) 30
An anonymous reader shared this report from Phoronix:
A patch series that appears destined for the upcoming Linux 7.3 merge window is what's dubbed the "KVM Chainsaw" as a major code clean-up in dealing with the kvm_mmu "god data structure". Red Hat engineer and KVM maintainer Paolo Bonzini has merged the kvm-chainsaw branch to KVM's "next" Git branch. With this KVM Chainsaw work now in the next branch, it should be submitted for the upcoming Linux 7.3 cycle.
The KVM Chainsaw work deals with the kvm_mmu structure being overloaded with multiple uses and splits it down into three parts for better handling current KVM usage. Paolo explains of KVM Chainsaw with the merge to the KVM.git next branch:
"The kvm_mmu is a "god data structure" that includes three different tasks: describing the guest page table's format, walking the guest page tables and building the page tables. This means that the (already poorly named) nested_mmu is only used in part, since it has no page tables to construct. Furthermore, some parts are reused across guest and host page tables (such as the reserved bits detector) but others are not; for example permission_fault is replaced by simplified code such as is_executable_pte().
This series cleans this up by splitting kvm_mmu in three parts...
The KVM Chainsaw work deals with the kvm_mmu structure being overloaded with multiple uses and splits it down into three parts for better handling current KVM usage. Paolo explains of KVM Chainsaw with the merge to the KVM.git next branch:
"The kvm_mmu is a "god data structure" that includes three different tasks: describing the guest page table's format, walking the guest page tables and building the page tables. This means that the (already poorly named) nested_mmu is only used in part, since it has no page tables to construct. Furthermore, some parts are reused across guest and host page tables (such as the reserved bits detector) but others are not; for example permission_fault is replaced by simplified code such as is_executable_pte().
This series cleans this up by splitting kvm_mmu in three parts...
But I thought... (Score:3, Funny)
Re: (Score:1)
Seriously, pick a new acronym. Same goes for DRM.
Re: (Score:2, Insightful)
I think the problem is that too many people picking acronyms know a lot less about tech than they think they do and fail to do minimal research. Kind of a small Dunning-Kruger effect.
Re: (Score:2)
I see the words.... (Score:3)
...but I'm unclear on how these changes would impact (or not) my life as a daily user of a linux desktop and occasional server. Not everyone is a kernel developer.
Re:I see the words.... (Score:5, Informative)
KVM is kernel virtual machine, and it is used to allow Linux to act as hypervisor.
Presumably as a desktop user and occasional server maintainer this does not affect you at all. Usually they work pretty hard to not break user land, but I imagine things like qemu or android studio that couple fairly tightly to KVM behavior might see performance gains or something if you update to versions aware of the platform changes.
Re: (Score:2)
It also may bring about additional functionality as time goes by, which can be useful. kvm is one of the few best of breed apps there is for what it does, and has an excellent reputation.
Re: (Score:2)
Re: (Score:3, Interesting)
This isn't going to affect you at all. Statistically nobody not working on KVM cares about this. It's almost exclusively just going to make KVM development easier. There is no reason why this should have hit the front page.
Re: (Score:2)
Exactly.
Re: (Score:1)
Any KVM fundamental changes can affect the kernel by changing resource allocation especially for user space. Applications are in some ways considered hyper featured virtual machines, at least some developers think so. There are even a few key kernel features that began as vm exclusive functionality actually lobbied in to app support.
Re: (Score:3)
It is essentially a detail-level optimization. No idea why it even gets reported here. Maybe Red Hat paid to have their name up there.
Re: (Score:3)
Why is this newsworthy? (Score:5, Insightful)
Nothing in the summary really conveys why this raises to the level of news. Digging in it doesn't really have consequences for the users in the short term.
Plausibly a good change, but a change among countless other good changes that pass without notice.
Re: (Score:2)
I completely agree. Maybe Red Hat paid to have their name up there. Or maybe it is a slow-news day.
Re: (Score:3)
Chainsaws are cool. Doom 2 had chainsaws. Therefore it's newsworthy.
I wonder what kind of chainsaw they used. Was it a Stihl?
Re: (Score:2)
Chainsaws are cool. Doom 2 had chainsaws. Therefore it's newsworthy.
I wonder what kind of chainsaw they used. Was it a Stihl?
Yeah. It was a Stihl.
Stihl Clickschitt model to be exact..
Re: (Score:3)
It would have been nice for the summary to at least clue in people who are unfamiliar with what KVM is in this context. overview was painful enough to read that after the first sentence, I didn't care.
Re: (Score:2)
Nothing in the summary really conveys why this raises to the level of news. Digging in it doesn't really have consequences for the users in the short term.
Plausibly a good change, but a change among countless other good changes that pass without notice.
Direct consequences for users in the short term, not many. But considering that most of the servers users interact with are on top of KVM, either as "Plain Vanilla" VMs, or Cloud Implementations (AWS runs on top of KVM, ditto for most of OpenStack), the indirect consequences of these changes quickly add up.
Re: (Score:2)
I presume that this "God data structure" is referring to the Higgs Bogon, the basis of the bogomips metric. Splitting the bogon is the first step to creating a kernel that can run on quantum computers. Or, possibly, the first step to causing vacuum collapse and the destruction of the universe as we know it. Hard to tell when messing with God stuff.
Re:Why is this newsworthy? (Score:5, Interesting)
Nothing in the summary really conveys why this raises to the level of news. Digging in it doesn't really have consequences for the users in the short term.
Plausibly a good change, but a change among countless other good changes that pass without notice.
I dunno. Given all the non-nerd news that shows up here, it's refreshing to see something more deeply technical, even if most of use who don't spend a lot of time thinking about VMs in Linux aren't directly affected.
I'd be fine with a bit more coverage of possibly-interesting kernel changes. I mean, /. shouldn't cover all of them; we have LWN for that. But picking the occasional random change of significance to highlight is worthwhile. Maybe one per week or something.
Re: (Score:2)
Re: (Score:2)
Also, going through the diff, it's not that large of a change either.
It's tricky code: yes, but it's essentially a cleanup.
News for nerds (Score:2)
nt
Performance impact? Or just maintenance impact? (Score:2)
Will this change have any change in performance for running multiple KVM machines in a cluster?
Or is this more for a more reliable code maintenance setup?
Did they win an award with this title? (Score:1)
Because the poster was obviously overextending themselves on this title of this story.
BKL (Score:2)
It's like a miniature version of the "big kernel lock" thing that took years to resolve.
Sure there were some blocking issues causing performance setbacks for it in certain locations but it was orders of magnitude more difficult to slice it out and replace things with smaller locks, and it still didn't have MASSIVE increases in performance or any user-visible way at all.
It's just code maintenance.