From: Alan Huang <mmpgouride@gmail.com>
To: paulmck@kernel.org, akiyks@gmail.com
Cc: perfbook@vger.kernel.org, Alan Huang <mmpgouride@gmail.com>
Subject: [PATCH] SMPDesign: Remove duplicate item
Date: Tue, 11 Apr 2023 12:28:05 -0400 [thread overview]
Message-ID: <20230411162805.1343469-1-mmpgouride@gmail.com> (raw)
Signed-off-by: Alan Huang <mmpgouride@gmail.com>
---
SMPdesign/criteria.tex | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/SMPdesign/criteria.tex b/SMPdesign/criteria.tex
index d3d84506..bc4d3a77 100644
--- a/SMPdesign/criteria.tex
+++ b/SMPdesign/criteria.tex
@@ -145,7 +145,7 @@ parallel program.
The larger the gap between the number of CPUs
and the actual speedup, the less efficiently the
CPUs will be used.
- Similarly, the greater the desired efficiency, the smaller
+ Similarly, the greater the desired efficiency, the bigger
the achievable speedup.
\item If the available synchronization primitives have
high overhead compared to the critical sections
@@ -157,11 +157,6 @@ parallel program.
using asymmetric primitives
(see \cref{chp:Deferred Processing}),
or by using a coarse-grained design such as \IXh{code}{locking}.
-\item If the critical sections have high overhead compared
- to the primitives guarding them, the best way
- to improve speedup is to increase parallelism
- by moving to reader/writer locking, \IXh{data}{locking}, asymmetric,
- or data ownership.
\item If the critical sections have high overhead compared
to the primitives guarding them and the data structure
being guarded is read much more often than modified,
--
2.34.1
next reply other threads:[~2023-04-11 16:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-11 16:28 Alan Huang [this message]
2023-04-12 0:16 ` [PATCH] SMPDesign: Remove duplicate item Akira Yokosawa
2023-04-12 1:15 ` Alan Huang
2023-04-12 2:51 ` Akira Yokosawa
2023-04-12 10:40 ` Alan Huang
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=20230411162805.1343469-1-mmpgouride@gmail.com \
--to=mmpgouride@gmail.com \
--cc=akiyks@gmail.com \
--cc=paulmck@kernel.org \
--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).