From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753623AbbETOEZ (ORCPT ); Wed, 20 May 2015 10:04:25 -0400 Received: from mail-pd0-f179.google.com ([209.85.192.179]:35529 "EHLO mail-pd0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753402AbbETOER (ORCPT ); Wed, 20 May 2015 10:04:17 -0400 Date: Wed, 20 May 2015 19:34:11 +0530 From: Viresh Kumar To: Thomas Gleixner Cc: linaro-kernel@lists.linaro.org, linux-kernel@vger.kernel.org, Ingo Molnar , Peter Zijlstra Subject: Re: [PATCH 0/2] clockevents: Hide CLOCK_EVT_STATE_* from rest of the kernel Message-ID: <20150520140411.GB22904@linux> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 On 20-05-15, 15:09, Thomas Gleixner wrote: > On Wed, 20 May 2015, Viresh Kumar wrote: > They look at clock_event_mode and not at state, right? Yeah, it was all useful (that's what I thought initially, but not anymore) only when we migrate some drivers to the new per-state APIs. > And that way we add the overhead of a full function call to those > drivers for the interrupt hot path? Honestly, I didn't realize that this can be a blocker. My bad. > Of course you should have done that analysis before posting some > random helper functions. I did looked at all the drivers few days back, but failed to give a summary similar to yours. No excuses. > Lets look how useful these functions are for the various use cases > > #1) Adds function call over head to the timer interrupt > > Hot path does matter and that function call is a regression. So > that's a NONO > Now explain me how your magic functions help. For most of the cases > they would be a performance regression. And for the rest they really > do not matter at all. They wouldn't help at all in that case. So, probably we are left with following choices: - Maintain state internally within the driver. SMP cases need per-cpu storage as clkevt devices are per-cpu. Probably that's a NONO as well ? - Use CLK_EVT_STATE_* directly in drivers (similar to the way we use CLK_EVT_MODE_* today). - Write the routines I proposed as macros or inline functions in clockchips.h, and use them. Of course that wouldn't stop exposing CLK_EVT_STATE_* to rest of the kernel. - Something else ? Which one do you suggest ? -- viresh