diff for duplicates of <20170817093612.024cc4bc.cohuck@redhat.com> diff --git a/a/content_digest b/N1/content_digest index d7c654d..01d9577 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,7 +2,7 @@ "ref\0b77b151f-e51d-3657-66e9-6fbc83887b18@suse.de\0" "From\0Cornelia Huck <cohuck@redhat.com>\0" "Subject\0Re: [PATCH RFC 0/2] KVM: use RCU to allow dynamic kvm->vcpus array\0" - "Date\0Thu, 17 Aug 2017 07:36:12 +0000\0" + "Date\0Thu, 17 Aug 2017 09:36:12 +0200\0" "To\0Alexander Graf <agraf@suse.de>\0" "Cc\0Radim Kr\304\215m\303\241\305\231 <rkrcmar@redhat.com>" linux-mips@linux-mips.org @@ -60,4 +60,4 @@ "well, no need to come up with a new one that will likely have its own\n" share of problems. -d91d8f1c8c5591fc62736f14111fc724f90669e88dddcb621cb9c80d48c0a6cd +706887cb80d9a6139f36ceed7365267c19be70068fe8fb2c433e3fb5ee03e7d2
diff --git a/a/1.txt b/N2/1.txt index f3bccad..0f56d43 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,7 +1,7 @@ On Thu, 17 Aug 2017 09:04:14 +0200 Alexander Graf <agraf@suse.de> wrote: -> On 16.08.17 21:40, Radim Krčmář wrote: +> On 16.08.17 21:40, Radim Kr?m?? wrote: > > The goal is to increase KVM_MAX_VCPUS without worrying about memory > > impact of many small guests. > > @@ -15,7 +15,7 @@ Alexander Graf <agraf@suse.de> wrote: > > start. The main advantage is that kvm->vcpus will work like it does > > now. It has been posted as "[PATCH 0/4] KVM: add KVM_CREATE_VM2 to > > allow dynamic kvm->vcpus array", -> > http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1377285.html +> > http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1377285.html > > > > The main problem of (2), this series, is that we cannot extend the array > > in place and therefore require some kind of protection when moving it. diff --git a/a/content_digest b/N2/content_digest index d7c654d..50b0d4c 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,29 +1,15 @@ "ref\020170816194037.9460-1-rkrcmar@redhat.com\0" "ref\0b77b151f-e51d-3657-66e9-6fbc83887b18@suse.de\0" - "From\0Cornelia Huck <cohuck@redhat.com>\0" - "Subject\0Re: [PATCH RFC 0/2] KVM: use RCU to allow dynamic kvm->vcpus array\0" - "Date\0Thu, 17 Aug 2017 07:36:12 +0000\0" - "To\0Alexander Graf <agraf@suse.de>\0" - "Cc\0Radim Kr\304\215m\303\241\305\231 <rkrcmar@redhat.com>" - linux-mips@linux-mips.org - linux-arm-kernel@lists.infradead.org - kvm@vger.kernel.org - kvm-ppc@vger.kernel.org - linux-kernel@vger.kernel.org - linux-s390@vger.kernel.org - Marc Zyngier <marc.zyngier@arm.com> - Christian Borntraeger <borntraeger@de.ibm.com> - James Hogan <james.hogan@imgtec.com> - Christoffer Dall <cdall@linaro.org> - Paul Mackerras <paulus@ozlabs.org> - David Hildenbrand <david@redhat.com> - " Paolo Bonzini <pbonzini@redhat.com>\0" + "From\0cohuck@redhat.com (Cornelia Huck)\0" + "Subject\0[PATCH RFC 0/2] KVM: use RCU to allow dynamic kvm->vcpus array\0" + "Date\0Thu, 17 Aug 2017 09:36:12 +0200\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On Thu, 17 Aug 2017 09:04:14 +0200\n" "Alexander Graf <agraf@suse.de> wrote:\n" "\n" - "> On 16.08.17 21:40, Radim Kr\304\215m\303\241\305\231 wrote:\n" + "> On 16.08.17 21:40, Radim Kr?m?? wrote:\n" "> > The goal is to increase KVM_MAX_VCPUS without worrying about memory\n" "> > impact of many small guests.\n" "> > \n" @@ -37,7 +23,7 @@ "> > start. The main advantage is that kvm->vcpus will work like it does\n" "> > now. It has been posted as \"[PATCH 0/4] KVM: add KVM_CREATE_VM2 to\n" "> > allow dynamic kvm->vcpus array\",\n" - "> > http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1377285.html\n" + "> > http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1377285.html\n" "> > \n" "> > The main problem of (2), this series, is that we cannot extend the array\n" "> > in place and therefore require some kind of protection when moving it.\n" @@ -60,4 +46,4 @@ "well, no need to come up with a new one that will likely have its own\n" share of problems. -d91d8f1c8c5591fc62736f14111fc724f90669e88dddcb621cb9c80d48c0a6cd +0e4623013d59826b1fb6bdfd15babd09ced10b5c779cc0ffa4cdc8b0fab8d184
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.