diff for duplicates of <20190906141858.GA3953@localhost.localdomain>

diff --git a/a/1.txt b/N1/1.txt
index 24e2cc0..51937aa 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -21,8 +21,3 @@ On Fri, Sep 06, 2019 at 09:48:21AM +0800, Ming Lei wrote:
 Why are all 8 nvmes sharing the same CPU for interrupt handling?
 Shouldn't matrix_find_best_cpu_managed() handle selecting the least used
 CPU from the cpumask for the effective interrupt handling?
-
-_______________________________________________
-Linux-nvme mailing list
-Linux-nvme@lists.infradead.org
-http://lists.infradead.org/mailman/listinfo/linux-nvme
diff --git a/a/content_digest b/N1/content_digest
index 447f332..e408a15 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -12,17 +12,17 @@
  "Subject\0Re: [PATCH 1/4] softirq: implement IRQ flood detection mechanism\0"
  "Date\0Fri, 6 Sep 2019 08:18:58 -0600\0"
  "To\0Ming Lei <ming.lei@redhat.com>\0"
- "Cc\0Jens Axboe <axboe@fb.com>"
+ "Cc\0Daniel Lezcano <daniel.lezcano@linaro.org>"
+  Keith Busch <keith.busch@intel.com>
   Hannes Reinecke <hare@suse.com>
-  John Garry <john.garry@huawei.com>
   Bart Van Assche <bvanassche@acm.org>
   linux-scsi@vger.kernel.org
   Peter Zijlstra <peterz@infradead.org>
   Long Li <longli@microsoft.com>
-  Daniel Lezcano <daniel.lezcano@linaro.org>
+  John Garry <john.garry@huawei.com>
   LKML <linux-kernel@vger.kernel.org>
   linux-nvme@lists.infradead.org
-  Keith Busch <keith.busch@intel.com>
+  Jens Axboe <axboe@fb.com>
   Ingo Molnar <mingo@redhat.com>
   Thomas Gleixner <tglx@linutronix.de>
   Christoph Hellwig <hch@lst.de>
@@ -51,11 +51,6 @@
  "\n"
  "Why are all 8 nvmes sharing the same CPU for interrupt handling?\n"
  "Shouldn't matrix_find_best_cpu_managed() handle selecting the least used\n"
- "CPU from the cpumask for the effective interrupt handling?\n"
- "\n"
- "_______________________________________________\n"
- "Linux-nvme mailing list\n"
- "Linux-nvme@lists.infradead.org\n"
- http://lists.infradead.org/mailman/listinfo/linux-nvme
+ CPU from the cpumask for the effective interrupt handling?
 
-b4dd1b73753e69ecd06a35206de870b15b7eddc735be86959e2f435b0a3a3cd5
+6b77e23c3c40a1eecf0719d11d7d7e9ccc69e2de85980c538e8285d1defe0c5a
