From: Thomas Gleixner <tglx@linutronix.de>
To: Stanislav Fomichev <stfomichev@yandex-team.ru>
Cc: viresh.kumar@linaro.org, paul.gortmaker@windriver.com,
peterz@infradead.org, stuart.w.hayes@gmail.com,
david.vrabel@citrix.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] hrtimers: add fast path to hrtimer_get_next_event
Date: Mon, 9 Jun 2014 16:44:54 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.10.1406091635080.3830@nanos> (raw)
In-Reply-To: <20140609125931.GL26511@stfomichev-desktop.yandex.net>
On Mon, 9 Jun 2014, Stanislav Fomichev wrote:
> In hrtimer_get_next_event we unconditionally lock/unlock spinlock, even if it's
> not required (hrtimer_hres_active() != 0). This patch adds fast path
> when highres is active so we don't execute unnecessary operations.
>
> We can safely do lockless check because:
> - hrtimer_get_next_event is always called with interrupts disabled;
> - we may switch to hres only from softirq handler with disabled interrupts.
>
> Because we only care about hres_active which may be changed only from
> local CPU, we can use interrupt context for synchronization.
>
> run_timer_softirq
> hrtimer_run_pending
> hrtimer_switch_to_hres
> local_irq_save <-
> base->hres_active = 0
>
> tick_nohz_idle_enter
> local_irq_disable <-
> __tick_nohz_idle_enter
> tick_nohz_stop_sched_tick
> get_next_timer_interrupt
> cmp_next_hrtimer_event
> hrtimer_get_next_event
> check base->hres_active
>
> irq_exit <- irq context
> tick_irq_exit
> tick_nohz_irq_exit
> tick_nohz_full_stop_tick
> tick_nohz_stop_sched_tick
> ... <see above>
> __tick_nohz_idle_enter
> ... <see above>
Sigh. Is anybody actually reading and trying to understand what I
write in reviews?
> Also the lockless check wants a comment why it is correct.
Is it that hard? A comment is NOT a uberlenghty explanation in the
changelog. A comment starts with /* and ends with */ and is in the
code.
/*
* Called with interrupts disabled and therefor
* protected against a switch to high resolution mode.
*/
That's a comment, right?
Thanks,
tglx
next prev parent reply other threads:[~2014-06-09 14:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-09 9:23 [PATCH] hrtimers: conditionally lock/unlock spinlock in hrtimer_get_next_event Stanislav Fomichev
2014-06-09 9:27 ` Viresh Kumar
2014-06-09 11:06 ` Thomas Gleixner
2014-06-09 11:11 ` Stanislav Fomichev
2014-06-09 12:59 ` [PATCH v2] hrtimers: add fast path to hrtimer_get_next_event Stanislav Fomichev
2014-06-09 13:28 ` Viresh Kumar
2014-06-10 7:42 ` Peter Zijlstra
2014-06-09 14:44 ` Thomas Gleixner [this message]
2014-06-10 9:46 ` [PATCH v3] " Stanislav Fomichev
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=alpine.DEB.2.10.1406091635080.3830@nanos \
--to=tglx@linutronix.de \
--cc=david.vrabel@citrix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=peterz@infradead.org \
--cc=stfomichev@yandex-team.ru \
--cc=stuart.w.hayes@gmail.com \
--cc=viresh.kumar@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome