Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752107AbbBMDtm (ORCPT ); Thu, 12 Feb 2015 22:49:42 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:36383 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751311AbbBMDtl (ORCPT ); Thu, 12 Feb 2015 22:49:41 -0500 Message-ID: <54DD7452.2000507@codeaurora.org> Date: Thu, 12 Feb 2015 19:49:38 -0800 From: Stephen Boyd User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Thompson , Thomas Gleixner , John Stultz CC: linux-kernel@vger.kernel.org, patches@linaro.org, linaro-kernel@lists.linaro.org, Sumit Semwal , Steven Rostedt Subject: Re: [PATCH v4 0/5] sched_clock: Optimize and avoid deadlock during read from NMI References: <1421859236-19782-1-git-send-email-daniel.thompson@linaro.org> <1423396960-4824-1-git-send-email-daniel.thompson@linaro.org> In-Reply-To: <1423396960-4824-1-git-send-email-daniel.thompson@linaro.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1424 Lines: 33 On 02/08/15 04:02, Daniel Thompson wrote: > This patchset optimizes the generic sched_clock implementation by > removing branches and significantly reducing the data cache profile. It > also makes it safe to call sched_clock() from NMI (or FIQ on ARM). > > The data cache profile of sched_clock() in the original code is > somewhere between 2 and 3 (64-byte) cache lines, depending on alignment > of struct clock_data. After patching, the cache profile for the normal > case should be a single cacheline. > > NMI safety was tested on i.MX6 with perf drowning the system in FIQs and > using the perf handler to check that sched_clock() returned monotonic > values. At the same time I forcefully reduced kt_wrap so that > update_sched_clock() is being called at >1000Hz. > > Without the patches the above system is grossly unstable, surviving > [9K,115K,25K] perf event cycles during three separate runs. With the > patch I ran for over 9M perf event cycles before getting bored. > Looks good to me. For the series: Reviewed-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/