lkml.org 
[lkml]   [2000]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: new IRQ scalability changes in 2.3.48

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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.164 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site