From: Sean Christopherson <seanjc@google.com>
To: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
"open list:KERNEL VIRTUAL MACHINE FOR MIPS (KVM/mips)"
<kvm@vger.kernel.org>, Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Maxim Levitsky <mlevitsk@redhat.com>,
Lai Jiangshan <jiangshan.ljs@antgroup.com>
Subject: Re: [PATCH 07/12] KVM: X86/MMU: Remove the useless struct mmu_page_path
Date: Thu, 21 Jul 2022 15:25:57 +0000 [thread overview]
Message-ID: <YtlwBcvU5ro11wuy@google.com> (raw)
In-Reply-To: <CAJhGHyB=-bGrguLKtTh+EAr5zr--H97HUgR3WP=JTovQLkoevQ@mail.gmail.com>
On Thu, Jul 21, 2022, Lai Jiangshan wrote:
> On Wed, Jul 20, 2022 at 4:15 AM Sean Christopherson <seanjc@google.com> wrote:
> >
> > Nit, s/useless/now-unused, or "no longer used". I associate "useless" in shortlogs
> > as "this <xyz> is pointless and always has been pointless", whereas "now-unused"
> > is likely to be interpreted as "remove <xyz> as it's no longer used after recent
> > changes".
> >
> > Alternatively, can this patch be squashed with the patch that removes
> > mmu_pages_clear_parents()? Yeah, it'll be a (much?) larger patch, but leaving
> > dead code behind is arguably worse.
>
> Defined by the C-language and the machine, struct mmu_page_path is used
> in for_each_sp() and the data is set and updated every iteration.
>
> It is not really dead code.
I'm not talking about just "struct mmu_page_path", but also the pointless updates
in for_each_sp(). And I think even if we're being super pedantic, it _is_ dead
code because C99 allows the compiler to drop code that the compiler can prove has
no side effects. I learned this the hard way by discovering that an asm() blob
with an output constraint will be elided if the output isn't consumed and the asm()
blob isn't tagged volatile.
In the abstract machine, all expressions are evaluated as specified by the
semantics. An actual implementation need not evaluate part of an expression if
it can deduce that its value is not used and that no needed side effects are
produced (including any caused by calling a function or accessing a volatile object)
I don't see any advantage to separating this from mmu_pages_clear_parents(). It
doesn't make the code any easier to review. I'd argue it does the opposite because
it makes it harder to see that mmu_pages_clear_parents() was the only user, i.e.
squashing this would provide further justification for dropping mmu_pages_clear_parents().
next prev parent reply other threads:[~2022-07-21 15:26 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-05 6:43 [PATCH 00/12] KVM: X86/MMU: Simpliy mmu_unsync_walk() Lai Jiangshan
2022-06-05 6:43 ` [PATCH 01/12] KVM: X86/MMU: Warn if sp->unsync_children > 0 in link_shadow_page() Lai Jiangshan
2022-06-05 6:43 ` [PATCH 02/12] KVM: X86/MMU: Rename kvm_unlink_unsync_page() to kvm_mmu_page_clear_unsync() Lai Jiangshan
2022-07-14 22:10 ` Sean Christopherson
2022-06-05 6:43 ` [PATCH 03/12] KVM: X86/MMU: Split a part of kvm_unsync_page() as kvm_mmu_page_mark_unsync() Lai Jiangshan
2022-07-14 22:19 ` Sean Christopherson
2022-06-05 6:43 ` [PATCH 04/12] KVM: X86/MMU: Remove mmu_pages_clear_parents() Lai Jiangshan
2022-07-14 23:15 ` Sean Christopherson
2022-06-05 6:43 ` [PATCH 05/12] KVM: X86/MMU: Clear unsync bit directly in __mmu_unsync_walk() Lai Jiangshan
2022-07-19 19:52 ` Sean Christopherson
2022-07-21 9:32 ` Lai Jiangshan
2022-07-21 16:26 ` Sean Christopherson
2022-06-05 6:43 ` [PATCH 06/12] KVM: X86/MMU: Rename mmu_unsync_walk() to mmu_unsync_walk_and_clear() Lai Jiangshan
2022-07-19 20:07 ` Sean Christopherson
2022-06-05 6:43 ` [PATCH 07/12] KVM: X86/MMU: Remove the useless struct mmu_page_path Lai Jiangshan
2022-07-19 20:15 ` Sean Christopherson
2022-07-21 9:43 ` Lai Jiangshan
2022-07-21 15:25 ` Sean Christopherson [this message]
2022-06-05 6:43 ` [PATCH 08/12] KVM: X86/MMU: Remove the useless idx from struct kvm_mmu_pages Lai Jiangshan
2022-07-19 20:31 ` Sean Christopherson
2022-06-05 6:43 ` [PATCH 09/12] KVM: X86/MMU: Unfold struct mmu_page_and_offset in " Lai Jiangshan
2022-06-05 6:43 ` [PATCH 10/12] KVM: X86/MMU: Don't add parents to " Lai Jiangshan
2022-07-19 20:34 ` Sean Christopherson
2022-06-05 6:43 ` [PATCH 11/12] KVM: X86/MMU: Remove mmu_pages_first() and mmu_pages_next() Lai Jiangshan
2022-07-19 20:40 ` Sean Christopherson
2022-06-05 6:43 ` [PATCH 12/12] KVM: X86/MMU: Rename struct kvm_mmu_pages to struct kvm_mmu_page_vec Lai Jiangshan
2022-07-19 20:45 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YtlwBcvU5ro11wuy@google.com \
--to=seanjc@google.com \
--cc=jiangshan.ljs@antgroup.com \
--cc=jiangshanlai@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=vkuznets@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox