Messages in this thread | | | Date | Mon, 23 Jun 2014 22:04:43 +0400 | From | Stanislav Fomichev <> | Subject | Re: [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 do for(;HRTIMER_MAX_CLOCK_BASES;).
| |