Messages in this thread | | | Date | Sat, 31 Jul 1999 23:00:08 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: Scheduling latencies news: less RAM = less latency |
| |
On Sun, 1 Aug 1999, Benno Senoner wrote:
> 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/
| |