On Sat, Aug 13, 2022 at 11:12:07AM +0900, Akira Yokosawa wrote: > Hi, > > A minor nit: > > On Fri, 12 Aug 2022 14:15:08 -0700, Paul E. McKenney wrote: > > On Fri, Aug 12, 2022 at 02:38:06PM -0400, Elad Lahav wrote: > >> Sent as an attachment because I'm behind a corporate firewall and can > >> only use Gmail's ^$*&^@# web interface. If that's not acceptable I'll > >> find another method to send a Real Text Email, just like mother nature > >> intended it to be. > > > > For the time being, it is fine. Longer term, it would be good to find > > a way to send a Real Text Email, for old time's sake. ;-) > > > > Queued and pushed, thank you! > > > > Thanx, Paul > > > >> --Elad > > > >> From 153cd4261fe58ed7f26bb0b1232eae2de43070ad Mon Sep 17 00:00:00 2001 > >> From: Elad Lahav <elahav@xxxxxxx> > >> Date: Fri, 12 Aug 2022 13:04:08 -0400 > >> Subject: [PATCH] count: The fast path is for the write side, not the read > >> side. > >> > >> Signed-off-by: Elad Lahav <e2lahav@xxxxxxxxx> > > So, the email addresses in From: and S-o-b: tags don't match. > > Technically speaking, this commit does not have its author's S-o-b:, > which means the lack of "Developer's Certificate of Origin". > > I think in this case, Paul can amend the author field of the commit > and force push. Good eyes, and thank you! I have adjusted the From: to match the Signed-of-by. Elad, does that match what you had in mind? > As for me, in my early contributions to perfbook, I misconfigured > git's user.email, and ended up in dozens of commits with S-o-b of > a non-reachable email address during April--May of 2016. :-/ I managed to do some very odd things when I started up with git as well. We all do. ;-) Thanx, Paul > Thanks, Akira > > >> --- > >> count/count.tex | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/count/count.tex b/count/count.tex > >> index 7e74d58f..523789e2 100644 > >> --- a/count/count.tex > >> +++ b/count/count.tex > >> @@ -2262,7 +2262,7 @@ be run all the way to either of its limits, but it does so at the > >> expense of adding atomic operations to the fastpaths, which slow down > >> the fastpaths significantly on some systems. > >> Although some workloads might tolerate this slowdown, it is worthwhile > >> -looking for algorithms with better read-side performance. > >> +looking for algorithms with better write-side performance. > >> One such algorithm uses a signal handler to steal counts from other > >> threads. > >> Because signal handlers run in the context of the signaled thread, > >> -- > >> 2.25.1 > >> > >
