lkml.org 
[lkml]   [2007]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
    On 2/22/07, Alan <alan@lxorguk.ukuu.org.uk> wrote:
    > > to do anything but chase pointers through cache. Done right, it
    > > hardly even branches (although the branch misprediction penalty is a
    > > lot less of a worry on current x86_64 than it was in the
    > > mega-superscalar-out-of-order-speculative-execution days). It's damn
    >
    > Actually it costs a lot more on at least one vendors processor because
    > you stall very long pipelines.

    You're right; I overreached there. I haven't measured branch
    misprediction penalties in dog's years (I focus more on system latency
    issues these days), so I'm just going on rumor. If your CPU vendor is
    still playing the tune-for-SpecINT-at-the-expense-of-real-code game
    (*cough* Itanic *cough*), get another CPU vendor -- while you still
    can.

    > > threadlets promise that they will not touch anything thread-local, and
    > > that when the FPU is handed to them in a specific, known state, they
    > > leave it in that same state. (Some of the flags can be
    >
    > We don't use the FPU in the kernel except in very weird cases where it
    > makes an enormous performance difference. The threadlets also have the
    > same page tables so they have the same %cr3 so its very cheap to switch,
    > basically a predicted jump and some register loads

    Do you not understand that real user code touches FPU state at
    unpredictable (to the kernel) junctures? Maybe not in a database or a
    web server, but in the GUIs and web-based monitoring applications that
    are 99% of the potential customers for kernel AIO? I have no idea
    what a %cr3 is, but if you don't fence off thread-local stuff from the
    threadlets you are just begging for end-user Heisenbugs and a place in
    the dustheap of history next to Symbolics LISP.

    > > Do me a favor. Do some floating point math and a memcpy() in between
    > > syscalls in the threadlet. Actually fiddle with errno and the FPU
    >
    > We don't have an errno in the kernel because its a stupid idea. Errno is
    > a user space hack for compatibility with 1970's bad design. So its not
    > relevant either.

    Dude, it's thread-local, and the glibc wrapper around most synchronous
    syscalls touches it. If you don't instantiate a new TLS context (or
    whatever the right lingo for that is) for every threadlet, you are
    TOAST -- if you let the user call stuff out of <stdlib.h> (let alone
    <stdio.h>) from within the threadlet.

    Cheers,
    - Michael
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-02-23 03:51    [W:4.085 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site