diff for duplicates of <ZrFezgVbCI3DRQH3@google.com> diff --git a/a/1.txt b/N1/1.txt index 27ae89b..2c057bc 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,7 +1,7 @@ On Sat, Aug 03, 2024, maobibo wrote: -> On 2024/8/3 ??3:32, Sean Christopherson wrote: +> On 2024/8/3 上午3:32, Sean Christopherson wrote: > > On Fri, Aug 02, 2024, maobibo wrote: -> > > On 2024/7/27 ??7:52, Sean Christopherson wrote: +> > > On 2024/7/27 上午7:52, Sean Christopherson wrote: > > > > Mark pages/folios dirty only the slow page fault path, i.e. only when > > > > mmu_lock is held and the operation is mmu_notifier-protected, as marking a > > > > page/folio dirty after it has been written back can make some filesystems @@ -10,7 +10,7 @@ On Sat, Aug 03, 2024, maobibo wrote: > > > > > > > > See the link below for details. > > > > -> > > > Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes at gmail.com +> > > > Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes@gmail.com > > > > Signed-off-by: Sean Christopherson <seanjc@google.com> > > > > --- > > > > arch/loongarch/kvm/mmu.c | 18 ++++++++++-------- diff --git a/a/content_digest b/N1/content_digest index cd6351f..7b58e2b 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,15 +4,39 @@ "ref\0Zq00OYowF5kc9QFE@google.com\0" "ref\0345d89c1-4f31-6b49-2cd4-a0696210fa7c@loongson.cn\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[PATCH v12 64/84] KVM: LoongArch: Mark \"struct page\" pfns dirty only in \"slow\" page fault path\0" + "Subject\0Re: [PATCH v12 64/84] KVM: LoongArch: Mark \"struct page\" pfns dirty only in \"slow\" page fault path\0" "Date\0Mon, 5 Aug 2024 16:22:54 -0700\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0maobibo <maobibo@loongson.cn>\0" + "Cc\0Paolo Bonzini <pbonzini@redhat.com>" + Marc Zyngier <maz@kernel.org> + Oliver Upton <oliver.upton@linux.dev> + Tianrui Zhao <zhaotianrui@loongson.cn> + Huacai Chen <chenhuacai@kernel.org> + Michael Ellerman <mpe@ellerman.id.au> + Anup Patel <anup@brainfault.org> + Paul Walmsley <paul.walmsley@sifive.com> + Palmer Dabbelt <palmer@dabbelt.com> + Albert Ou <aou@eecs.berkeley.edu> + Christian Borntraeger <borntraeger@linux.ibm.com> + Janosch Frank <frankja@linux.ibm.com> + Claudio Imbrenda <imbrenda@linux.ibm.com> + kvm@vger.kernel.org + linux-arm-kernel@lists.infradead.org + kvmarm@lists.linux.dev + loongarch@lists.linux.dev + linux-mips@vger.kernel.org + linuxppc-dev@lists.ozlabs.org + kvm-riscv@lists.infradead.org + linux-riscv@lists.infradead.org + linux-kernel@vger.kernel.org + David Matlack <dmatlack@google.com> + " David Stevens <stevensd@chromium.org>\0" "\00:1\0" "b\0" "On Sat, Aug 03, 2024, maobibo wrote:\n" - "> On 2024/8/3 ??3:32, Sean Christopherson wrote:\n" + "> On 2024/8/3 \344\270\212\345\215\2103:32, Sean Christopherson wrote:\n" "> > On Fri, Aug 02, 2024, maobibo wrote:\n" - "> > > On 2024/7/27 ??7:52, Sean Christopherson wrote:\n" + "> > > On 2024/7/27 \344\270\212\345\215\2107:52, Sean Christopherson wrote:\n" "> > > > Mark pages/folios dirty only the slow page fault path, i.e. only when\n" "> > > > mmu_lock is held and the operation is mmu_notifier-protected, as marking a\n" "> > > > page/folio dirty after it has been written back can make some filesystems\n" @@ -21,7 +45,7 @@ "> > > > \n" "> > > > See the link below for details.\n" "> > > > \n" - "> > > > Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes at gmail.com\n" + "> > > > Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes@gmail.com\n" "> > > > Signed-off-by: Sean Christopherson <seanjc@google.com>\n" "> > > > ---\n" "> > > > arch/loongarch/kvm/mmu.c | 18 ++++++++++--------\n" @@ -102,4 +126,4 @@ "because the vast majority of time the loss in accuracy has no effect, and the worst\n" case scenario is that the kernel does I/O that wasn't necessary. -f468eea0fd69daeb045aeb7cf6a250948b629da9848b7e191b366637c5b5e395 +a7a847a285921963205acefb650b446453399859f74042d01f1da1363b45e440
diff --git a/a/1.txt b/N2/1.txt index 27ae89b..11bcacd 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,7 +1,7 @@ On Sat, Aug 03, 2024, maobibo wrote: -> On 2024/8/3 ??3:32, Sean Christopherson wrote: +> On 2024/8/3 上午3:32, Sean Christopherson wrote: > > On Fri, Aug 02, 2024, maobibo wrote: -> > > On 2024/7/27 ??7:52, Sean Christopherson wrote: +> > > On 2024/7/27 上午7:52, Sean Christopherson wrote: > > > > Mark pages/folios dirty only the slow page fault path, i.e. only when > > > > mmu_lock is held and the operation is mmu_notifier-protected, as marking a > > > > page/folio dirty after it has been written back can make some filesystems @@ -10,7 +10,7 @@ On Sat, Aug 03, 2024, maobibo wrote: > > > > > > > > See the link below for details. > > > > -> > > > Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes at gmail.com +> > > > Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes@gmail.com > > > > Signed-off-by: Sean Christopherson <seanjc@google.com> > > > > --- > > > > arch/loongarch/kvm/mmu.c | 18 ++++++++++-------- @@ -90,3 +90,8 @@ mmu_notifiers) is technically unsafe. In other words, the intent is to sacrifice accuracy to improve stability/robustness, because the vast majority of time the loss in accuracy has no effect, and the worst case scenario is that the kernel does I/O that wasn't necessary. + +_______________________________________________ +linux-riscv mailing list +linux-riscv@lists.infradead.org +http://lists.infradead.org/mailman/listinfo/linux-riscv diff --git a/a/content_digest b/N2/content_digest index cd6351f..f1e8fc5 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -4,15 +4,39 @@ "ref\0Zq00OYowF5kc9QFE@google.com\0" "ref\0345d89c1-4f31-6b49-2cd4-a0696210fa7c@loongson.cn\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[PATCH v12 64/84] KVM: LoongArch: Mark \"struct page\" pfns dirty only in \"slow\" page fault path\0" + "Subject\0Re: [PATCH v12 64/84] KVM: LoongArch: Mark \"struct page\" pfns dirty only in \"slow\" page fault path\0" "Date\0Mon, 5 Aug 2024 16:22:54 -0700\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0maobibo <maobibo@loongson.cn>\0" + "Cc\0Paolo Bonzini <pbonzini@redhat.com>" + Marc Zyngier <maz@kernel.org> + Oliver Upton <oliver.upton@linux.dev> + Tianrui Zhao <zhaotianrui@loongson.cn> + Huacai Chen <chenhuacai@kernel.org> + Michael Ellerman <mpe@ellerman.id.au> + Anup Patel <anup@brainfault.org> + Paul Walmsley <paul.walmsley@sifive.com> + Palmer Dabbelt <palmer@dabbelt.com> + Albert Ou <aou@eecs.berkeley.edu> + Christian Borntraeger <borntraeger@linux.ibm.com> + Janosch Frank <frankja@linux.ibm.com> + Claudio Imbrenda <imbrenda@linux.ibm.com> + kvm@vger.kernel.org + linux-arm-kernel@lists.infradead.org + kvmarm@lists.linux.dev + loongarch@lists.linux.dev + linux-mips@vger.kernel.org + linuxppc-dev@lists.ozlabs.org + kvm-riscv@lists.infradead.org + linux-riscv@lists.infradead.org + linux-kernel@vger.kernel.org + David Matlack <dmatlack@google.com> + " David Stevens <stevensd@chromium.org>\0" "\00:1\0" "b\0" "On Sat, Aug 03, 2024, maobibo wrote:\n" - "> On 2024/8/3 ??3:32, Sean Christopherson wrote:\n" + "> On 2024/8/3 \344\270\212\345\215\2103:32, Sean Christopherson wrote:\n" "> > On Fri, Aug 02, 2024, maobibo wrote:\n" - "> > > On 2024/7/27 ??7:52, Sean Christopherson wrote:\n" + "> > > On 2024/7/27 \344\270\212\345\215\2107:52, Sean Christopherson wrote:\n" "> > > > Mark pages/folios dirty only the slow page fault path, i.e. only when\n" "> > > > mmu_lock is held and the operation is mmu_notifier-protected, as marking a\n" "> > > > page/folio dirty after it has been written back can make some filesystems\n" @@ -21,7 +45,7 @@ "> > > > \n" "> > > > See the link below for details.\n" "> > > > \n" - "> > > > Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes at gmail.com\n" + "> > > > Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes@gmail.com\n" "> > > > Signed-off-by: Sean Christopherson <seanjc@google.com>\n" "> > > > ---\n" "> > > > arch/loongarch/kvm/mmu.c | 18 ++++++++++--------\n" @@ -100,6 +124,11 @@ "\n" "In other words, the intent is to sacrifice accuracy to improve stability/robustness,\n" "because the vast majority of time the loss in accuracy has no effect, and the worst\n" - case scenario is that the kernel does I/O that wasn't necessary. + "case scenario is that the kernel does I/O that wasn't necessary.\n" + "\n" + "_______________________________________________\n" + "linux-riscv mailing list\n" + "linux-riscv@lists.infradead.org\n" + http://lists.infradead.org/mailman/listinfo/linux-riscv -f468eea0fd69daeb045aeb7cf6a250948b629da9848b7e191b366637c5b5e395 +5ab37bf7b790523801f9cd66a96c9f5e3139e2ba85418d54aa8ea305ab8da84c
diff --git a/a/1.txt b/N3/1.txt index 27ae89b..2c057bc 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -1,7 +1,7 @@ On Sat, Aug 03, 2024, maobibo wrote: -> On 2024/8/3 ??3:32, Sean Christopherson wrote: +> On 2024/8/3 上午3:32, Sean Christopherson wrote: > > On Fri, Aug 02, 2024, maobibo wrote: -> > > On 2024/7/27 ??7:52, Sean Christopherson wrote: +> > > On 2024/7/27 上午7:52, Sean Christopherson wrote: > > > > Mark pages/folios dirty only the slow page fault path, i.e. only when > > > > mmu_lock is held and the operation is mmu_notifier-protected, as marking a > > > > page/folio dirty after it has been written back can make some filesystems @@ -10,7 +10,7 @@ On Sat, Aug 03, 2024, maobibo wrote: > > > > > > > > See the link below for details. > > > > -> > > > Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes at gmail.com +> > > > Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes@gmail.com > > > > Signed-off-by: Sean Christopherson <seanjc@google.com> > > > > --- > > > > arch/loongarch/kvm/mmu.c | 18 ++++++++++-------- diff --git a/a/content_digest b/N3/content_digest index cd6351f..f569fd8 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -4,15 +4,38 @@ "ref\0Zq00OYowF5kc9QFE@google.com\0" "ref\0345d89c1-4f31-6b49-2cd4-a0696210fa7c@loongson.cn\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[PATCH v12 64/84] KVM: LoongArch: Mark \"struct page\" pfns dirty only in \"slow\" page fault path\0" + "Subject\0Re: [PATCH v12 64/84] KVM: LoongArch: Mark \"struct page\" pfns dirty only in \"slow\" page fault path\0" "Date\0Mon, 5 Aug 2024 16:22:54 -0700\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0maobibo <maobibo@loongson.cn>\0" + "Cc\0kvm@vger.kernel.org" + linux-kernel@vger.kernel.org + David Matlack <dmatlack@google.com> + linux-riscv@lists.infradead.org + Claudio Imbrenda <imbrenda@linux.ibm.com> + Marc Zyngier <maz@kernel.org> + Janosch Frank <frankja@linux.ibm.com> + Huacai Chen <chenhuacai@kernel.org> + Christian Borntraeger <borntraeger@linux.ibm.com> + Albert Ou <aou@eecs.berkeley.edu> + loongarch@lists.linux.dev + Paul Walmsley <paul.walmsley@sifive.com> + kvmarm@lists.linux.dev + linux-arm-kernel@lists.infradead.org + linux-mips@vger.kernel.org + Oliver Upton <oliver.upton@linux.dev> + Palmer Dabbelt <palmer@dabbelt.com> + David Stevens <stevensd@chromium.org> + kvm-riscv@lists.infradead.org + Anup Patel <anup@brainfault.org> + Paolo Bonzini <pbonzini@redhat.com> + Tianrui Zhao <zhaotianrui@loongson.cn> + " linuxppc-dev@lists.ozlabs.org\0" "\00:1\0" "b\0" "On Sat, Aug 03, 2024, maobibo wrote:\n" - "> On 2024/8/3 ??3:32, Sean Christopherson wrote:\n" + "> On 2024/8/3 \344\270\212\345\215\2103:32, Sean Christopherson wrote:\n" "> > On Fri, Aug 02, 2024, maobibo wrote:\n" - "> > > On 2024/7/27 ??7:52, Sean Christopherson wrote:\n" + "> > > On 2024/7/27 \344\270\212\345\215\2107:52, Sean Christopherson wrote:\n" "> > > > Mark pages/folios dirty only the slow page fault path, i.e. only when\n" "> > > > mmu_lock is held and the operation is mmu_notifier-protected, as marking a\n" "> > > > page/folio dirty after it has been written back can make some filesystems\n" @@ -21,7 +44,7 @@ "> > > > \n" "> > > > See the link below for details.\n" "> > > > \n" - "> > > > Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes at gmail.com\n" + "> > > > Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes@gmail.com\n" "> > > > Signed-off-by: Sean Christopherson <seanjc@google.com>\n" "> > > > ---\n" "> > > > arch/loongarch/kvm/mmu.c | 18 ++++++++++--------\n" @@ -102,4 +125,4 @@ "because the vast majority of time the loss in accuracy has no effect, and the worst\n" case scenario is that the kernel does I/O that wasn't necessary. -f468eea0fd69daeb045aeb7cf6a250948b629da9848b7e191b366637c5b5e395 +cb909f79fa9ee1eced6b6850ee05b0448a90b4deeac270ccf6fe324b5f731f49
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.