Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751231Ab3JTHe7 (ORCPT ); Sun, 20 Oct 2013 03:34:59 -0400 Received: from rhlx01.hs-esslingen.de ([129.143.116.10]:60413 "EHLO rhlx01.hs-esslingen.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751077Ab3JTHe6 (ORCPT ); Sun, 20 Oct 2013 03:34:58 -0400 Date: Sun, 20 Oct 2013 09:34:56 +0200 From: Andreas Mohr To: Frederic Weisbecker Cc: Oleg Nesterov , Peter Zijlstra , LKML , Frederic Weisbecker , Fernando Luis Vazquez Cao , Tetsuo Handa , Thomas Gleixner , Ingo Molnar Subject: Re: [PATCH 3/5] timer: Change idle/iowait accounting semantics Message-ID: <20131020073456.GA2729@rhlx01.hs-esslingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1382195841-6558-4-git-send-email-fweisbec@gmail.com> X-Priority: none User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1576 Lines: 47 Hi, just wanted to report that this capricious open-coded (ok, lone-coded :) converter: +static inline ktime_t us_to_ktime(u64 us) +{ + static const ktime_t ktime_zero = { .tv64 = 0 }; + + return ktime_add_us(ktime_zero, us); +} triggered a virtual red flag in my processing. We obviously seem to be compensating for a domain mismatch here: + iowait = get_cpu_iowait_time_us(cpu, NULL); + + if (ktime_compare(idle, us_to_ktime(iowait)) > 0) + idle = ktime_sub_us(idle, iowait); + And sure enough: get_cpu_iowait_time_us() does a final to-us conversion only right before result is returned, and it's located right within the same build unit (tick-sched.c). (and then we go ahead and do a from-us round trip :-P) So, in case we want to standardize on ktime_t domain for these parts of purely *in-kernel* time handling, how about adding a _unit-local_ helper for providing a ktime-only result and convert get_cpu_iowait_time_us() into a simple to-us *external user code* one-line wrapper for it? (and include updates to all other places which would benefit from this change) And preferably launch such patch as a preparatory patch for this subsequent 3/5 patch, within the series? Unless I missed some other restrictions which cause us to need to cling to that manual from-us conversion, for now or forever... Andreas Mohr -- 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/