All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <ZDcDxecF0Y5F0pV6@slm.duckdns.org>

diff --git a/a/1.txt b/N1/1.txt
index 31a6468..daeb228 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -18,7 +18,7 @@ On Wed, Apr 12, 2023 at 02:40:53PM -0400, Waiman Long wrote:
 > > > the same. So the same check must be present in both cpuset_fork() and
 > > > cpuset_can_fork() to make sure that attach_in_progress is correctly set.
 > > > 
-> > > Signed-off-by: Waiman Long <longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
+> > > Signed-off-by: Waiman Long <longman@redhat.com>
 > > Waiman, I'm not necessarily against this optimization but can we at least
 > > have some performance numbers to show that this is actually meaningful?
 > > Given how heavy our fork path is, I'm not too sure this would show up in any
diff --git a/a/content_digest b/N1/content_digest
index f43a956..cbe9b6b 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -2,20 +2,19 @@
  "ref\020230411133601.2969636-6-longman@redhat.com\0"
  "ref\0ZDb4G2jgQFK8h8Ys@slm.duckdns.org\0"
  "ref\090b7bc16-0673-02b7-dad1-f24bc956f1c5@redhat.com\0"
- "ref\090b7bc16-0673-02b7-dad1-f24bc956f1c5-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org\0"
- "From\0Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>\0"
+ "From\0Tejun Heo <tj@kernel.org>\0"
  "Subject\0Re: [PATCH v4 5/5] cgroup/cpuset: Optimize out unneeded cpuset_can_fork/cpuset_cancel_fork calls\0"
  "Date\0Wed, 12 Apr 2023 09:17:25 -1000\0"
- "To\0Waiman Long <longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>\0"
- "Cc\0Zefan Li <lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>"
-  Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
-  Christian Brauner <brauner-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
-  cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Juri Lelli <juri.lelli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
-  Dietmar Eggemann <dietmar.eggemann-5wv7dgnIgG8@public.gmane.org>
- " Michal Koutn\303\275 <mkoutny-IBi9RG/b67k@public.gmane.org>"
- " Giuseppe Scrivano <gscrivan-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>\0"
+ "To\0Waiman Long <longman@redhat.com>\0"
+ "Cc\0Zefan Li <lizefan.x@bytedance.com>"
+  Johannes Weiner <hannes@cmpxchg.org>
+  Christian Brauner <brauner@kernel.org>
+  cgroups@vger.kernel.org
+  linux-kernel@vger.kernel.org
+  Juri Lelli <juri.lelli@redhat.com>
+  Dietmar Eggemann <dietmar.eggemann@arm.com>
+ " Michal Koutn\303\275 <mkoutny@suse.com>"
+ " Giuseppe Scrivano <gscrivan@redhat.com>\0"
  "\00:1\0"
  "b\0"
  "Hello,\n"
@@ -38,7 +37,7 @@
  "> > > the same. So the same check must be present in both cpuset_fork() and\n"
  "> > > cpuset_can_fork() to make sure that attach_in_progress is correctly set.\n"
  "> > > \n"
- "> > > Signed-off-by: Waiman Long <longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>\n"
+ "> > > Signed-off-by: Waiman Long <longman@redhat.com>\n"
  "> > Waiman, I'm not necessarily against this optimization but can we at least\n"
  "> > have some performance numbers to show that this is actually meaningful?\n"
  "> > Given how heavy our fork path is, I'm not too sure this would show up in any\n"
@@ -67,4 +66,4 @@
  "-- \n"
  tejun
 
-a81c955c01cfecd73964de7be4bbd9d9d07557e661d91d85353d4da7b3ace8c4
+6f35036961e871e33da1b74575a1ff5ca9b601f0f4aa0c7c74a78a534cc04bf9

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.