From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:mime-version:content-type; bh=CIjSHNOoOC7ON2raMNRz/qt6Ibq1FHFQlLUr5iB4quI=; b=0eEnnjysN3lrbCliTcS30UnkMicaeFsgRQQShCxAuo46isNUnfDx/3XCuyBgz712nJ kc3Ih15PKBwWRJYNgqpo3PzosJOZyDuaJzJPny+ZLHg8znR5RPmU75EWEP+yg8zMHK4c JEYNYxCf/FHRAGw0IuB8Xcuwo3Ah0TOtUzrJLl0bCz6wLwrALN3/C+YfqxKvj8cmbMuO hzRDeqFadcClBuPj0gJ4NxvGubSmpMMXc/yIijNuCPaQjNGE+uUc6rl6B2SdizA85Vq4 YWxCBCmz6g7B3Nb1DCRHORZDPYgFUzLlsjo5JyXuFLQDyXw2WJWMDQxpeq5fBERQ+6bA ZNbA== Date: Sun, 21 Feb 2016 16:52:44 +0900 Message-ID: <87io1ixzxv.wl%mitake.hitoshi@gmail.com> From: Hitoshi Mitake Subject: Re: [PATCH 2/2] Let a writer thread go back to the original CPU in the toy RCU pseudocode In-Reply-To: <20160221053020.GK3522@linux.vnet.ibm.com> References: <1455958322-25225-1-git-send-email-mitake.hitoshi@gmail.com> <1455958322-25225-2-git-send-email-mitake.hitoshi@gmail.com> <20160221053020.GK3522@linux.vnet.ibm.com> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII To: paulmck@linux.vnet.ibm.com Cc: Hitoshi Mitake , perfbook@vger.kernel.org List-ID: Hi Paul, At Sat, 20 Feb 2016 21:30:20 -0800, Paul E. McKenney wrote: > > 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 > > 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. Thanks a lot for your review. I couldn't consider about atomicity of the CPU state, the affinity of the thread, etc. I assumed the atomicity is provided and this assumption is wrong. Again, thanks for your time and review. Your review improved my understanding of RCU :) # BTW, how do you think about the change of the figure in the 1st # patch? Of couse I'm not sure it is worth to apply or not. Thanks, Hitoshi > > 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 > > >