All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1368213757.19683.10@snotra>

diff --git a/a/1.txt b/N1/1.txt
index 715890a..cdfe951 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,15 +1,15 @@
 On 05/10/2013 12:57:33 PM, Alexander Graf wrote:
-> Could you guys please collect performance data during the next weeks =20
-> on both guest-directed ISIs as well as VF MMIOs (preferably with =20
-> in-kernel MMIO), so that we can decide on the direction that's worth =20
+> Could you guys please collect performance data during the next weeks  
+> on both guest-directed ISIs as well as VF MMIOs (preferably with  
+> in-kernel MMIO), so that we can decide on the direction that's worth  
 > going towards?
 
-Collecting data on VF MMIO would require implementing it (or at least =20
-salvaging and fixing some old code), which is not a high priority at =20
-the moment.  If we do implement VF in the future we could always undo =20
-the direct ISI change, but it would still be nice to know if there's =20
+Collecting data on VF MMIO would require implementing it (or at least  
+salvaging and fixing some old code), which is not a high priority at  
+the moment.  If we do implement VF in the future we could always undo  
+the direct ISI change, but it would still be nice to know if there's  
 any real benefit in the first place.
 
 FWIW, I doubt that the "more stress on HW TLB" will be significant.
 
--Scott=
+-Scott
diff --git a/a/content_digest b/N1/content_digest
index e474043..ea1b654 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -12,19 +12,19 @@
  "\00:1\0"
  "b\0"
  "On 05/10/2013 12:57:33 PM, Alexander Graf wrote:\n"
- "> Could you guys please collect performance data during the next weeks =20\n"
- "> on both guest-directed ISIs as well as VF MMIOs (preferably with =20\n"
- "> in-kernel MMIO), so that we can decide on the direction that's worth =20\n"
+ "> Could you guys please collect performance data during the next weeks  \n"
+ "> on both guest-directed ISIs as well as VF MMIOs (preferably with  \n"
+ "> in-kernel MMIO), so that we can decide on the direction that's worth  \n"
  "> going towards?\n"
  "\n"
- "Collecting data on VF MMIO would require implementing it (or at least =20\n"
- "salvaging and fixing some old code), which is not a high priority at =20\n"
- "the moment.  If we do implement VF in the future we could always undo =20\n"
- "the direct ISI change, but it would still be nice to know if there's =20\n"
+ "Collecting data on VF MMIO would require implementing it (or at least  \n"
+ "salvaging and fixing some old code), which is not a high priority at  \n"
+ "the moment.  If we do implement VF in the future we could always undo  \n"
+ "the direct ISI change, but it would still be nice to know if there's  \n"
  "any real benefit in the first place.\n"
  "\n"
  "FWIW, I doubt that the \"more stress on HW TLB\" will be significant.\n"
  "\n"
- -Scott=
+ -Scott
 
-c2bdd4031e76147a4b5e2329eaa7afeca473cd60a1fcf3c85c1d095bf589aeec
+64386fb8cb41ddbd7ba6c608fc15dc79a8d99f1eab1362f1bac3163aec918de8

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.