I _am_ pragmatic. That which works, works, and theory can go screw itself.
However, my pragmatism also extends to maintainability, which is why I
also want it done well.
> I can
> see 2 possibilities from here:
>
> 1) your revulsion at "random" scheduling points is a really strong
> belief that would likely make convincing you of the value of
> each particular point impossible,
I want more than an explanation like "I ran our latency tester, and this
point seemed to be really bad, so I added a scheduling point here".
For example, for the specific read/write user-copy code, I don't even need
to get numbers. It's clear that with a machine that has tons of memory,
and where the data is cached, we can generate a "read()" system call that
spends quite a lot of time without needing any active re-scheduling. This
is not a random point: it's something that can be clearly explained from
the sources, and a case where there clearly is no better solution unless
you fully thread the thing.
> 2) you you accept the idea that there may need to be a bunch of
> "random" scheduling points for this to work, and whilst you
> consider this ugly, you accept that there isn't much of an
> alternative. people will have to have a lot of good numbers
> to convince you to apply a patch that adds a scheduling point.
More than just numbers, but yes. I'd like to know that the code isn't just
crap. For example, let's say that something uses an O(n^3) algorithm, and
to "overcome" the expense of this thing we add scheduling points in it.
That's the easy way to do it. But maybe the right thing to do is to
realize that the code may be badly structured in the first place?
> Can someone explain what is meant by getting the UP-threaded kernel to
> work ok, and how this would impact scheduling jitter ? If a kernel
> thread blocks interrupts for a long time, how can it help to have a
> multi-threaded kernel ?
If the kernel blocks interrupts for a long time, adding re-scheduling
points won't help. You must not schedule with interrupts blocked anyway.
The multi-threaded UP-kernel depends on the fine-grained locks that we
_already_ have, as a result of SMP threading. We don't use them at all on
UP: which is quite nice from a performance perspective, because a no-op is
always faster than threading something. But we could use them
intelligently, and get a UP kernel that can be pre-empted 90% of the time.
Making the explicit scheduling points much less of an issue..
Linus
-
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/