> > It doesn't have to run mostly in the kernel. It just has to be in the
> > kernel when the I/O-bound tasks awakes. Further, there are plenty of
>
> How does that work? Won't the switch happen on exit from the kernel?
Sure, but we have essentially unbounded times in the kernel ...
I/O-bound tasks shouldn't have to wait for do_try_to_free_pages to
finish for some lower priority process.
> > what we consider CPU-bound tasks that are interactive and/or
> > graphics-oriented and this adds much to their time in the kernel.
>
> I'm not sure what an "interactive and/or graphics-oriented" CPU bound
> task might be. Is there a definition?
I'm talking about today's GUI application. It does computation and its
riddled with bloated GUI code. So it is certainly CPU bound. At the
same time it is interactive (blocking or polling on user input) and
involves some graphics output. So it is involved in I/O, too. What
would you consider it?
> So you think of an "I/O bound task" as "an I/O bound task that spends
> most of its timeblocked". Won't the latencies of such tasks already be
> pretty high? I'd think that better caching and read-ahead is the correct
> fix.
I should correct myself, I didn't mean "most of its time" but a
statistically large portion. All it needs to do is find itself woken
when something else is in the kernel.
> > While we certainly need tangible empirical benefits, users finding their
> > desktop experience smoother and thus more enjoyable is just about the
> > best thing we can ask for.
>
> It depends on what you want.
I want a better kernel.
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/