From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Hitoshi Mitake <mitake.hitoshi@gmail.com>
Cc: perfbook@vger.kernel.org
Subject: Re: [PATCH 2/2] Let a writer thread go back to the original CPU in the toy RCU pseudocode
Date: Sat, 20 Feb 2016 21:30:20 -0800 [thread overview]
Message-ID: <20160221053020.GK3522@linux.vnet.ibm.com> (raw)
In-Reply-To: <1455958322-25225-2-git-send-email-mitake.hitoshi@gmail.com>
On Sat, Feb 20, 2016 at 05:52:02PM +0900, Hitoshi Mitake wrote:
> This commit a little bit improves the logic of a writer thread. The
> new logic lets the writer go back to the original CPU after run_on()
> the final CPU.
>
> Of course it is a trivial improvement and the original two lines
> pseudocode is beautiful. If it isn't worth to apply, please ignore it.
>
> Signed-off-by: Hitoshi Mitake <mitake.hitoshi@gmail.com>
Hello, Hitoshi,
Thank you for the submission, but each addition of this sort invites
another. For example, you capture the initial CPU, but suppose that
the thread was originally bound to a pair of CPUs? Wouldn't you then
want to restore the binding to that pair of CPUs?
But if you did that, suppose that both of those CPUs went offline
while going through the for_each_online_cpu() loop? Wouldn't you
need to instead bind to some CPUs that were actually online?
And suppose that some other CPU changed the binding of the thread
just after you captured the initial binding? Wouldn't you want to
reflect that change (give or take CPU hotplug operations) at the
end of the loop?
And it just gets worse from there. So we need to keep this one
simple, which means that I cannot accept this patch.
Thanx, Paul
> ---
> defer/rcuintro.tex | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/defer/rcuintro.tex b/defer/rcuintro.tex
> index 03d6e12..135922c 100644
> --- a/defer/rcuintro.tex
> +++ b/defer/rcuintro.tex
> @@ -166,8 +166,11 @@ quite complex, a toy implementation is exceedingly simple:
> \begin{minipage}[t]{\columnwidth}
> \scriptsize
> \begin{verbatim}
> - 1 for_each_online_cpu(cpu)
> - 2 run_on(cpu);
> + 1 int orig_cpu = smp_processor_id();
> + 2 for_each_online_cpu(cpu)
> + 3 run_on(cpu);
> + 4 if (orig_cpu != smp_processor_id())
> + 5 run_on(orig_cpu);
> \end{verbatim}
> \end{minipage}
> \vspace{5pt}
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe perfbook" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2016-02-22 2:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-20 8:52 [PATCH 1/2] Improve the figure of QSBR Hitoshi Mitake
2016-02-20 8:52 ` [PATCH 2/2] Let a writer thread go back to the original CPU in the toy RCU pseudocode Hitoshi Mitake
2016-02-21 5:30 ` Paul E. McKenney [this message]
2016-02-21 7:52 ` Hitoshi Mitake
2016-02-20 13:27 ` [PATCH 1/2] Improve the figure of QSBR Hitoshi Mitake
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=20160221053020.GK3522@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=mitake.hitoshi@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.