> Right, being able to control this interactivity knob programmatically
> seems like a useful thing. That way, the window manager can boost the
> interactivity of the foreground window for example. It does seem that
> figuring out that something is interactive in the scheduler is tough,
> there is just not enough information, whereas a higher layer may know
> this for a fact. I guess this reduces my argument to just keeping the
> interactivity setting separate from priority.
No no no. Martin's point shows exactly that nothing but the kernel can
ever know whether a task is I/O or CPU bound. What is bash? Is it
interactive (when you are typing into it) or CPU bound (when its running
a script or doing other junk)?
Only the kernel knows exactly the sleep patterns of tasks, which is
essentially whether or not a task is interactive.
Finally, the windows manager idea is bad. The foreground window may
have dependencies elsewhere, and giving it a boost only partially solves
the problem.
I think with Linus's patch, the problem is solved, because we boost both
I/O-bound tasks and tasks that help I/O bound tasks.
Robert Love
-
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/