Messages in this thread | | | Date | Mon, 8 Jun 2015 19:11:25 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [PATCH 0/3] hrtimer: HRTIMER_STATE_ fixes |
| |
On Mon, 8 Jun 2015, Peter Zijlstra wrote: > On Mon, 2015-06-08 at 17:10 +0200, Oleg Nesterov wrote: > > On 06/08, Peter Zijlstra wrote: > > > > > > > I tend to agree, but I think its a pre-existing problem, not one > > > > introduced by my proposed patch. > > > > > > Something like this would fix that I think. It fully preserves > > > timer->state over hrtimer_start_range_ns(). > > > > Yes, but I think we can do a bit better. > > > > Only for initial review, I need to re-check this... > > I'm having a wee bit of bother spotting how you version is 'better'. > > > And. I think that after you remove STATE_CALLBACK we can even kill > > timer->state altogether, but this is another story. > > Ah, yes, we could introduce timerqueue_is_queued() which uses > RB_EMPTY_NODE(). Obviating the need for hrtimer::state entirely.
Which won't work for the migration case unless we have some trickery like we do with double linked lists (not setting the prev member to NULL on dequeue).
Thanks,
tglx
| |