Messages in this thread | | | Date | Sat, 24 Apr 2010 07:56:52 +0200 | From | Pavel Machek <> | Subject | Re: CPUfreq - udelay() interaction issues |
| |
Hi!
> Seems a bit more complicated than what I had in mind. This is > touching the scheduler I think we can get away without having to. > Also, there is no simple implementation for the "slowpath" that can > guarantee the delay without starting over the loop and hoping not to > get interrupted or just giving up and doing a massively inaccurate > delay (like msleep, etc). > > I was thinking of something along the lines of this: > > udelay() > { > if (!is_atomic()) > down_read(&freq_sem); > /* else > do nothing since cpufreq can't interrupt you. > */ > > call usual code since cpufreq is not going to preempt you. > > if (!is_atomic()) > up_read(&freq_sem); > }
Well, most delays are very short, so...
What about... we decide that cpufreq interruption or switch to different cpu takes 100usec minimum, and only try to do complex magic for delays >100usec? Hopefully there's minimum of those :-).
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |