Any additional overhead is clearly small - enough not to disrupt a *high
resolution* timer, after all. And msleep() is used mostly during
initialization time. My box had a few hundred calls, almost all during
boot. Any cost will be bounded by the fact that, well, it sleeps for
milliseconds on every call.
I could run a million-msleep profile if you really want, but I just
can't imagine it's going to have a measurable effect on any real-world
situation. Is there a specific setup you're worried about?
I'm not *that* attached to this patch; if it causes heartburn we can
just forget it. But I had thought it might be useful...
drivers/media/video/cafe_ccic.c, and cafe_smbus_write_data() in
particular. The "hidden problem," though, is that the hardware has
periods where reading the status registers will send it off into its
room where it will hide under its bed and never come out.
I have an alternative which avoids the sleep at the cost of a small,
relatively harmless race; it may be my real solution in the end, we'll
see.
My understanding is that the current dyntick code only turns off the
tick during idle periods; while things are running it's business as
usual. Perhaps I misunderstood?
jon
-
