On Thu, 9 Mar 2000, Andrea Arcangeli wrote:
> >> Having said this, i now do agree that doing a preemptible kernel (which
> >> the Linux SMP kernel could become with a small amount of work) is a
> >> superior solution to this, wrt. latencies.
>
> Ingo, how do you plan to handle the by-hand locks? You can trivially
> forbid rescheduling as soon as you have a spin_lock() held, but how do you
> handle code that uses a spinlock to serialize the accesses to a lock?
well, such code has to be fixed/changed. There are other (i believe
nastier) cases as well: rescheduling processes holding critical
semaphores. All the lock inversion scenarios pop up full force in a
preemptible kernel :-)
> And since most of the stuff needs some kind of serialization it also mean
> for most of syscalls you are going to reschedule in the ret_from_syscall
> stage anyway as now.
yep - a preemptible kernel does impact performance, no doubt about it. But
the real cost is in the UP kernel: spinlocks are not a no-op with
preemtible kernels anymore. (this can be helped with, but it's still
additional code)
> I think one of the only interesting places for the preemtable kernel is
> copy user stuff that will effectivly be rescheduled as soon as it's
> necessary.
i'm not sure. Basically we have moved away from unbound copies, so i doubt
any code in the kernel does more than a 64k copy at once to/from
user-space. The typical copy is not bigger than 4k. So an explicit
preemption point does help.
A 'fully preemtive' kernel is almost certainly a loss for typical systems,
but it's quite useful for RT applications. (it might also be useful for
interactive applications, although we are pretty good already with the
lowlatency-patch.)
> But now by thinking at that stuff I have an idea! Why instead of making
> the kernel preemtable we take the other way around? So why instead of
> having to forbid scheduling in locked regions, we don't simply allow
> rescheduling in some piece of code that we know that will benefit by the
> preemtable thing?
this is way too ugly and non-generic. You are completely missing the
point. uaccess.h latencies are _not_ the problem.
> That's all. Then we'll have copu_user preemtable with a few lines of
> changes. I'll try that immediatly :).
Andrea, please think first and do not duplicate work done by others. A
preemtive kernel is _not_ an issue unless you are into RT applications
which need 100 usec-type latencies. A current kernel's interactive
performance is already good enough to never show up in interactive
applications. Those few multimedia applications which need 0.5ms-ish
latencies are helped by the lowlatency patch.
Ingo
-
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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:24 EST