[lkml]   [2014]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2] hrtimers: calculate expires_next after all timers are executed
> So in case the enqueued timer is earlier than base0->next, you are
> looking at the wrong data. Same as in the current code and why you
> started to look into this at all.
Right, even if we do a local enqueue from higher base timer into lower base we
still need to update base->next in the enqueue.

> See above WHY it does NOT work.
It works, but without reprogramming in __remove_hrtimer we can end up with a
spurious tick which will just rearm clockdev and do no useful work.
At least no stall :-/

> No, we're not going to add another one in the first place as I know
> how MAY COME works: it translates to NEVER, unless I do it myself.
I'm fine with that, the point I'm trying to make is that I didn't even think
about any cleanup/refactoring in the first place, I just tried to get an
issue fixed and get some feedback. It's even better if we can also do a
cleanup in the process.

> > > Untested patch which addresses the issues below.
> > Aside from a small nitpick below, looks reasonable, I'll try to run it on a
> > couple of machines.
> > Should I send you a v3 afterwards with the changelog or
> > tested-by would be enough?
> Tested-by is fine. I can cobble a changelog together.
Ok, I have a couple of machines running for ~5 hours without any visible
issues, but let's give it at least a day.

> > > + while (active) {
> > > + idx = __ffs(active);
> > > + active &= ~(1UL << idx);
> > Is there any reason you did that instead of conventional:
> I thought about using __ffs before, just never came around it.
Nothing against it, seems totally legit, just looks inconsistent.
Now we have one place where we do __ffs stuff and other places where we

 \ /
  Last update: 2014-06-23 20:41    [W:0.037 / U:4.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site