From patchwork Mon Jul 22 18:21:19 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Stultz X-Patchwork-Id: 2831545 Return-Path: X-Original-To: patchwork-linux-arm-msm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 234DD9F243 for ; Mon, 22 Jul 2013 18:21:44 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 507CF202F1 for ; Mon, 22 Jul 2013 18:21:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 45D88202E6 for ; Mon, 22 Jul 2013 18:21:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932347Ab3GVSVY (ORCPT ); Mon, 22 Jul 2013 14:21:24 -0400 Received: from mail-pd0-f170.google.com ([209.85.192.170]:64256 "EHLO mail-pd0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756784Ab3GVSVX (ORCPT ); Mon, 22 Jul 2013 14:21:23 -0400 Received: by mail-pd0-f170.google.com with SMTP id x11so7148509pdj.15 for ; Mon, 22 Jul 2013 11:21:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=LYPwm0aSvGN2jGrVQBlQStSRkt7ikAO0JiNVfN3KAUs=; b=oR9686i1ZRNGjK8afeQgUVr+d4K1B4wddY7A1TklTh/Ng/S/bsvMf0xiZlVA6p2H28 m5+WIENTfaO2mvrIB2PL20oMh25QTJelbZCLBgn5GM7cPrtSza9kUh61kMfZWSQ1RsJX hsuM5nSK2O/gqavcy16hdB5CfVh1lHydAvJrqiWqW2n/t5AXWC07gNSOcMCMakRChBhG Bbvsr4bsjvAUITO13JWC4oolWY4FA2JcqSeVkdlKRUO3A6gp2Rsy1sjC6bnIH2WK8tAH eC95ki93n784XihMl5aOmwI7JI+5qJ9/hKexMRX1J/0SvySZ78lC4uguPPc6PSNl5voI eHgA== X-Received: by 10.66.40.212 with SMTP id z20mr23601740pak.51.1374517282400; Mon, 22 Jul 2013 11:21:22 -0700 (PDT) Received: from [192.168.122.27] (c-67-170-153-23.hsd1.or.comcast.net. [67.170.153.23]) by mx.google.com with ESMTPSA id om2sm37086369pbb.34.2013.07.22.11.21.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 11:21:21 -0700 (PDT) Message-ID: <51ED781F.6060300@linaro.org> Date: Mon, 22 Jul 2013 11:21:19 -0700 From: John Stultz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Boyd CC: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Russell King , Catalin Marinas , Will Deacon , Christopher Covington Subject: Re: [PATCH v4 03/17] sched_clock: Use an hrtimer instead of timer References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org> <1374189690-10810-4-git-send-email-sboyd@codeaurora.org> In-Reply-To: <1374189690-10810-4-git-send-email-sboyd@codeaurora.org> X-Gm-Message-State: ALoCoQlzWvepJrAz1bE6tpS9EGyFeDgTx2PcUWrtDZ3mko/uqdqZvY+rMvkxQEb4jr3s4Iy9ROmn Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org X-Spam-Status: No, score=-8.3 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 07/18/2013 04:21 PM, Stephen Boyd wrote: > In the next patch we're going to increase the number of bits that > the generic sched_clock can handle to be greater than 32. With > more than 32 bits the wraparound time can be larger than what can > fit into the units that msecs_to_jiffies takes (unsigned int). > Luckily, the wraparound is initially calculated in nanoseconds > which we can easily use with hrtimers, so switch to using an > hrtimer. > > Cc: Russell King > Signed-off-by: Stephen Boyd Hrmm. So in my testing (under qemu), this patch causes bootup to hang. qemu-system-arm -kernel zImage-arm -M vexpress-a9 -cpu cortex-a9 -nographic -m 1024 -append 'root=/dev/mmcblk0p2 rw mem=1024M raid=noautodetect console=ttyAMA0,38400n8 rootwait vmalloc=256MB devtmpfs.mount=0' -sd test-arm.img -redir tcp:4300::22 Config file attached. I haven't gotten a chance to look very closely, but it seems the folowing patch resolves the issue. I'm not sure if we're seeing callers to setup_sched_clock happen after sched_clock_postinit or what, but it probably needs another look over. thanks -john diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c index a269890b..c018ffc 100644 --- a/kernel/time/sched_clock.c +++ b/kernel/time/sched_clock.c @@ -138,12 +138,6 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate) pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns\n", bits, r, r_unit, res, wrap); - /* - * Start the timer to keep sched_clock() properly updated and - * sets the initial epoch. - */ - hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); - sched_clock_timer.function = sched_clock_poll; update_sched_clock(); /* @@ -175,6 +169,13 @@ void __init sched_clock_postinit(void) setup_sched_clock(jiffy_sched_clock_read, 32, HZ); update_sched_clock(); + + /* + * Start the timer to keep sched_clock() properly updated and + * sets the initial epoch. + */ + hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); + sched_clock_timer.function = sched_clock_poll; hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL); }