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:2.443 / U:1.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site