From: Viresh Kumar <viresh.kumar@linaro.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linaro-kernel@lists.linaro.org, linux-kernel@vger.kernel.org,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 0/2] clockevents: Hide CLOCK_EVT_STATE_* from rest of the kernel
Date: Wed, 20 May 2015 19:34:11 +0530 [thread overview]
Message-ID: <20150520140411.GB22904@linux> (raw)
In-Reply-To: <alpine.DEB.2.11.1505201411500.4225@nanos>
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
next prev parent reply other threads:[~2015-05-20 14:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-20 9:06 [PATCH 0/2] clockevents: Hide CLOCK_EVT_STATE_* from rest of the kernel Viresh Kumar
2015-05-20 9:06 ` [PATCH 1/2] clockevents: Move 'enum clock_event_state' to tick-internal.h Viresh Kumar
2015-05-20 9:06 ` [PATCH 2/2] clockevents: Add helpers to verify state of a clockevent device Viresh Kumar
2015-05-20 13:09 ` [PATCH 0/2] clockevents: Hide CLOCK_EVT_STATE_* from rest of the kernel Thomas Gleixner
2015-05-20 14:04 ` Viresh Kumar [this message]
2015-05-20 14:20 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150520140411.GB22904@linux \
--to=viresh.kumar@linaro.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.