From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753439AbbBEBsJ (ORCPT ); Wed, 4 Feb 2015 20:48:09 -0500 Received: from cdptpa-outbound-snat.email.rr.com ([107.14.166.232]:56078 "EHLO cdptpa-oedge-vip.email.rr.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752347AbbBEBsH (ORCPT ); Wed, 4 Feb 2015 20:48:07 -0500 Date: Wed, 4 Feb 2015 20:48:38 -0500 From: Steven Rostedt To: Stephen Boyd Cc: Daniel Thompson , Thomas Gleixner , John Stultz , linux-kernel@vger.kernel.org, patches@linaro.org, linaro-kernel@lists.linaro.org, Sumit Semwal , Russell King , Will Deacon , Catalin Marinas Subject: Re: [PATCH v3 4/4] sched_clock: Avoid deadlock during read from NMI Message-ID: <20150204204838.65411577@grimm.local.home> In-Reply-To: <20150205012351.GC30372@codeaurora.org> References: <1421859236-19782-1-git-send-email-daniel.thompson@linaro.org> <1422644602-11953-1-git-send-email-daniel.thompson@linaro.org> <1422644602-11953-5-git-send-email-daniel.thompson@linaro.org> <20150205012351.GC30372@codeaurora.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 4 Feb 2015 17:23:51 -0800 Stephen Boyd wrote: > On 01/30, Daniel Thompson wrote: > > @@ -98,26 +98,50 @@ unsigned long long notrace sched_clock(void) > > } > > > > /* > > + * Updating the data required to read the clock. > > + * > > + * sched_clock will never observe mis-matched data even if called from > > + * an NMI. We do this by maintaining an odd/even copy of the data and > > + * steering sched_clock to one or the other using a sequence counter. > > + * In order to preserve the data cache profile of sched_clock as much > > + * as possible the system reverts back to the even copy when the update > > + * completes; the odd copy is used *only* during an update. > > + */ > > +static void update_clock_read_data(struct clock_read_data *rd) > > notrace? Why? Isn't this for update, not for readers? -- Steve > > > +{ > > + /* update the backup (odd) copy with the new data */ > > + cd.read_data[1] = *rd; > > + > > + /* steer readers towards the new data */ > > s/new data/odd copy/? > > > + raw_write_seqcount_latch(&cd.seq); > > + > > + /* now its safe for us to update the normal (even) copy */ > > + cd.read_data[0] = *rd; > > + > > + /* switch readers back to the even copy */ > > + raw_write_seqcount_latch(&cd.seq); > > +} > > + > > +/* > > >