On Thursday, May 12, 2005 3:15 pm, George Anzinger wrote:
> The timers that cause the problem are the ones that only run when the
> task is active. These are the slice timer, the profile timer
> (ITIMER_PROF), the execution limit timer and the settime timer that
> is relative to execution time (ITIMER_VIRTUAL).
ITIMER_PROF could simply be ignored if the task it corresponds to isn't
active when it fires, so it wouldn't incur any overhead.
ITIMER_VIRTUAL sounds like it would uglify things though, and of course
unused timer slice interrupts would have to be cleared out.
> Again, we can colapse all these to one, but still it needs to be
> setup when the task is switched to and removed when it is switched
> away.
Right, I see what you're saying now. It's not as simple as I had hoped.
> Timers that run on system time (ITIMER_REAL) stay in the list even
> when the task is inactive.
Right, they'll cause the task they're associated with to become runnable
again, or get a signal, or whatever.
> I think there is already an IPI to tell another cpu that it has work.
> That should be enough. Need to check, however. From the VST point
> of view, any interrupt wake the cpu from the VST sleep, so it need
> not even target the scheduler..
But in this case you probably want it to, so it can rebalance tasks to
the CPU that just woke up.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]