Messages in this thread | | | Date | Mon, 16 Jul 2007 08:57:22 -0700 | From | "Ray Lee" <> | Subject | Re: [PATCH/RFC] msleep() with hrtimers |
| |
On 7/16/07, Roman Zippel <zippel@linux-m68k.org> wrote: > On Mon, 16 Jul 2007, Jonathan Corbet wrote: > > > One possible problem here is that setting up that timer can be > > > considerably more expensive, for a relative timer you have to read the > > > current time, which can be quite expensive (e.g. your machine now uses the > > > PIT timer, because TSC was deemed unstable). > > > > That's a possibility, I admit I haven't benchmarked it. I will say that > > I don't think it will be enough to matter - msleep() is not a hot-path > > sort of function. Once the system is up and running it almost never > > gets called at all - at least, on my setup. > > That's a bit my problem - we have to consider other setups as well. > Is it worth converting all msleep users behind their back or should we > just a provide a separate function for those who care?
As a driver author (2.4 timeframe, embedded platform, see gitinc.com for the hardware description), I would rather msleep did what it says it's going to do. If the current one can wait 20 times longer than you ask for, then that's just broken.
> > > One question here would be, is it really a problem to sleep a little more? > > > > "A little more" is a bit different than "twenty times as long as you > > asked for." That "little bit more" added up to a few seconds when > > programming a device which needs a brief delay after tweaking each of > > almost 200 registers. > > Which driver is this? I'd like to look at this, in case there's some other > hidden problem.
"Hidden problem"? Lots of hardware has quiescent wait-time requirements, to guarantee that whatever is going on it it's little state machine head finally reaches a stable state. Waiting for those changes to take effect before starting the next set of register reprogramming is a common requirement -- on the hardware I've worked with at least.
Ray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |