linux-kernel - Re: [RFC] [PATCH 1/1] hrtimers: Cache next hrtimer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 28 Aug 2009 01:16:13 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Ashwin Chaugule <ashwinc@...eaurora.org>
cc:	linux-kernel@...r.kernel.org, mingo@...hat.com
Subject: Re: [RFC] [PATCH 1/1] hrtimers: Cache next hrtimer

On Thu, 27 Aug 2009, Ashwin Chaugule wrote:
> Thomas Gleixner wrote:
> > You forgot to describe the application scenario which triggers this.
> >    
> I didn't have anything specific running in userspace to trigger this. The
> sched_timer itself was causing most of the unnecessary reprogramming. I
> reckon, with more applications running, the timer_stats will show other timers
> (hrtimer_wakeup, it_real_fn etc.) that cause this effect too.

Hmm. That's related to NOHZ I guess. Ok, that's a serious issue and we
need to look at that.

> > So if I'm not totally on the wrong track, that's the meat of the
> > patch.
> >   
> Yup.
> > Any reason why we can't solve that problem with checking
> > cpu_base->expires_next against the timer which is deleted ? 
> > See the patently untested patch below.
> > 
> > Another question which arises is whether we should bother with the
> > reprogramming at all and just let the last programmed event happen
> > even when the corresponding timer has been removed.
> >   
> Hm. Interesting approach. See below.
> 
> So, you suggest checking the ktime of the hrtimer thats about to expire and
> compare it with expires_next ?

What's wrong with that ?

> I guess, another reason to go with caching the hrtimer is to avoid looping
> through HRTIMER_MAX_CLOCK_BASES, which may increase to more than 2 (?) for
> other architectures, and also all the code flow to arm the clock events
> device.
> With the caching approach, I also saw a 4% speedup in various application
> startups too.

Can you reevaluate against my patch please ?

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/