From: Elad Lahav <e2lahav@gmail.com>
To: "perfbook@vger.kernel.org" <perfbook@vger.kernel.org>
Subject: Comments on chapter 5
Date: Wed, 10 Aug 2022 21:22:53 -0400 [thread overview]
Message-ID: <CAJbg=FUxuy++utmmuGpetP2wMk_Hc8UVYu74JWucmw9kxdM57A@mail.gmail.com> (raw)
Hi Paul,
I have a few comments on chapter 5. If you agree with any of them I
can try to provide a patch.
5.2.2: Not really related to counters. Is it really possible for the
compiler to use any location for temporary storage, even global
variables? That seems a bit excessive on the compiler's part. I have
definitely seen GCC reuse stack storage, but even then only when it
thought that the previous value there was out of scope (erroneously in
my case, as the function behaved like setjmp()).
5.2.3: Perhaps the code should be updated to use ISO C instead of GCC?
_Thread_local and inline are part of the language.
Listing 5.5: There is a mix of thread_id_t from CodeSamples and
pthread_create() from POSIX. One of those should be changed.
5.2.4: The wording suggests that the counting threads are not impacted
by the reader. But doesn't a cache line changing from Modified to
Shared incur a cost on the counter when it next comes to update the
value?
5.3.2: "references only per-thread variables, and should not incur any
cache misses" - except that the thread can migrate to other cores and
can thus incur cache misses.
5.3.3: I think that some clarification, or a simple example, is due
for explaining how a failure can occur when the count is nowhere near
the global max.
5.4.2: "it is worthwhile looking for algorithms with better read-side
performance" - should it not be "write-side performance"?
--Elad
next reply other threads:[~2022-08-11 1:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-11 1:22 Elad Lahav [this message]
2022-08-12 1:08 ` Comments on chapter 5 Paul E. McKenney
2022-08-13 13:47 ` Elad Lahav
2022-08-13 23:15 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJbg=FUxuy++utmmuGpetP2wMk_Hc8UVYu74JWucmw9kxdM57A@mail.gmail.com' \
--to=e2lahav@gmail.com \
--cc=perfbook@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).