> I think "reschedules" during lenghty kernel operations is not a so bad
> idea, [...]
i think you have a misconception - the concept of decreasing latencies in
a mandatory way is nothing new to Linux, we've been doing it for quite
some time. (mem.c, lp.c, etc.) We just have to export it to all affected
places - now that bigger memory boxes became widespread. We already (of
course!) do 'reschedules during lengthy kernel operations', when the need
arises, we just dont do it explicitly when _another_ process wants us to
reschedule. The patch i've sent fills this hole - more coming.
> I'm easily willing to trade 1-5% of the CPU in exchange of a responsive
> <5ms latency system.
my guesstimate is that we will not see any numbers getting worse.
Actually, some RL numbers will get much better. (eg. i can already log in
much faster during heavy kernel compiles) The thing you missed i think is
that we do not have to do a reschedule, we just have to check the (local)
->need_resched flag at a couple of well-chosen places. (see the patch)
> If the performance drop worries you, we could add this as a compile time
> option, "kernel optimized for server", or "kernel optimized for
> multimedia" .
you are arguing the wrong point ... Latency _is_ top priority in Linux.
And it's not hard to get it, it's hard to _measure_ it reliably. (and this
is why your tool is so cool.)
> If's ridiculous to get up to 150ms latencies on a powerful machine like
> the PII400 on Linux.
i can get excellent latencies on my box, without giving up speed - good
enough?
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/