From: "Paul E. McKenney" <paulmck@kernel.org>
To: Hao Lee <haolee.swjtu@gmail.com>
Cc: perfbook@vger.kernel.org
Subject: Re: The answer of Quiz C.8 is not quite reasonable
Date: Sun, 17 Apr 2022 10:44:54 -0700 [thread overview]
Message-ID: <20220417174454.GR4285@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <20220414174225.GA29861@haolee.io>
On Thu, Apr 14, 2022 at 05:42:25PM +0000, Hao Lee wrote:
> Hi,
>
> At the beginning of C.3.3 we have supposed the cache line containing "a"
> resides _only_ in _CPU1’s_ cache. I think this is why _CPU0_ has to send
> a "_read_ invalidate message" to _retrieve_ the cache line and invalid
> CPU1's cache line.
>
> However, the answer says the reason is the cache line in question
> contains more than just the variable a. I can't understand the logical
> relationship between this answer and the question. Am I missing
> something here? Thanks.
I added the commit shown below. Does that help?
Thanx, Paul
------------------------------------------------------------------------
commit 36fe14d5ebe406e331a5d89533fe3187d2019898
Author: Paul E. McKenney <paulmck@kernel.org>
Date: Sun Apr 17 10:41:33 2022 -0700
appendix/whymb: Clarify QQ C.8
More clearly note the presence of data other than the variable a.
Reported-by: Hao Lee <haolee.swjtu@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
diff --git a/appendix/whymb/whymemorybarriers.tex b/appendix/whymb/whymemorybarriers.tex
index 8f607e35..43f1307b 100644
--- a/appendix/whymb/whymemorybarriers.tex
+++ b/appendix/whymb/whymemorybarriers.tex
@@ -821,9 +821,14 @@ Then the sequence of operations might be as follows:
In \cref{seq:app:whymb:Store Buffers and Memory Barriers} above,
why does CPU~0 need to issue a ``read invalidate''
rather than a simple ``invalidate''?
+ After all, \co{foo()} will overwrite \co{a} in any case, so why
+ should it care about the old value of \co{a}?
}\QuickQuizAnswer{
- Because the cache line in question contains more than just the
+ Because the cache line in question contains more data than just the
variable \co{a}.
+ Issuing ``invalidate'' instead of the needed ``read invalidate''
+ would cause that other data to be lost, which would constitute
+ a serious bug in the hardware.
}\QuickQuizEnd
The hardware designers cannot help directly here, since the CPUs have
next prev parent reply other threads:[~2022-04-17 17:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-14 17:42 The answer of Quiz C.8 is not quite reasonable Hao Lee
2022-04-17 17:44 ` Paul E. McKenney [this message]
2022-04-18 8:01 ` Hao Lee
2022-04-19 17:28 ` Paul E. McKenney
2022-04-20 6:45 ` Hao Lee
2022-04-20 18:15 ` Paul E. McKenney
2022-04-21 13:34 ` Hao Lee
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=20220417174454.GR4285@paulmck-ThinkPad-P17-Gen-1 \
--to=paulmck@kernel.org \
--cc=haolee.swjtu@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 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.