All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.