lkml.org 
[lkml]   [2007]   [Feb]   [23]   [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
    I wrote:
    > (On a pre-EABI ARM, there is even a substantial
    > cache-related penalty for encoding the syscall number in the syscall
    > opcode, because you have to peek back at the text segment to see it,
    > which costs you a D-cache stall.)

    Before you say it, I'm aware that this is not directly relevant to TLS
    switch costs, except insofar as the "arch-dependent syscalls"
    introduced for certain parts of ARM TLS handling carry the same
    overhead as any other syscall. My point is that the system impact of
    seemingly benign operations is not always predictable even to the arch
    experts, and therefore one should be "parsimonious" (to use Kahan's
    word) in defining what semantics programmers may rely on in
    performance-critical situations.

    If you arrange things so that threadlets are scheduled as much as
    possible in bursts that share the same processor context (process
    context, location in program text, TLS arena, FPU state -- basically
    everything other than stack and integer registers), you are giving
    yourself and future designers the maximum opportunity for exploiting
    hardware optimizations. This would be a good thing if you want
    threadlets to be performance-competitive with state machine designs.

    If you still allow application programmers to _use_ shared processor
    state, in the knowledge that it will be clobbered on threadlet switch,
    then threadlets can use most of the coding style with which
    programmers of event-driven frameworks are familiar. This would be a
    good thing if you want threadlets to get wider use than the innards of
    three or four databases and web servers.

    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-24 03:19    [W:4.948 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site