Messages in this thread |  | | Date | Thu, 9 Apr 2015 11:18:36 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] hrtimer: Replace cpu_base->active_bases with a direct check of the active list |
| |
* Thomas Gleixner <tglx@linutronix.de> wrote:
> On Thu, 9 Apr 2015, Ingo Molnar wrote: > > Btw., does cpu_base->active_bases even make sense? hrtimer bases are > > fundamentally percpu, and to check whether there are any pending > > timers is a very simple check: > > > > base->active->next != NULL > > > > So I'd rather suggest taking a direct look at the head, instead of > > calculating bit positions, masks, etc. > > > > Furthermore, we never actually use cpu_base->active_bases as a > > 'summary' value (which is the main point of bitmasks in general), > > so I'd remove that complication altogether. > > > > This would speed up various hrtimer primitives like > > hrtimer_remove()/add and simplify the code. It would be a net code > > shrink as well. > > Well. You trade a bit more code against touching cache lines to > figure out whether the clock base has active timers or not. So for a > lot of scenarios where only clock monotonic is used you touch 3 > cache lines for nothing.
In the (typical) case it will touch one extra cacheline - and removes a fair bit of complexity which 80 bytes (that touches two cachelines):
7502 427 0 7929 1ef9 hrtimer.o.before 7422 427 0 7849 1ea9 hrtimer.o.after
So even if we were to optimize for cache footprint (which isn't the only factor we optimize for)it looks like a win-win scenario to me, even if you ignore the speedup and the simpler code structure...
Ok?
> I'm about to send out a patch which actually makes better use of the > active_bases field without creating a code size explosion.
So please lets do this series first - it achieves the same thing, with less cache used and faster code.
Thanks,
Ingo
|  |