lkml.org 
[lkml]   [2007]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Subjectx86 hardware and transputers (Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3)
    Date
    From
    > From: "Michael K. Edwards"
    > Newsgroups: gmane.linux.kernel
    > Subject: Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
    > Date: Thu, 22 Feb 2007 00:59:10 -0800

    [striping cc list]

    []
    > On 2/21/07, Ingo Molnar <mingo@elte.hu> wrote:
    >> > [...] As for threadlets, making them kernel threads is not such a good
    >> > design feature, O(1) scheduler or not. You take the full hit of
    >> > kernel task creation, on the spot, for every threadlet that blocks.
    >> > [...]
    >>
    >> this is very much not how they work. Threadlets share the same basic
    >> infrastructure with syslets and they do /not/ take a 'full hit of kernel
    >> thread creation' when they block. Please read the announcements, past
    >> discussions on lkml and the code about how it works.
    []
    > Yes, I will go back and read the code for myself. This will take me
    > some time because I have only a hand-waving level of knowledge about
    > task_structs and pt_regs, and have largely avoided the dark corners of
    > the x86 architecture.

    This architecture was brought to us by windows on our screens. And it
    took years (a decade?) for them to use all hardware features:

    (IA-32, i386) --> (MS Windows NT,9X)

    Yet you must still do much system programming to use that features.

    While

    > But I think my point still stands: allowing code inside threadlets to
    > use the usual C library wrappers around the usual synchronous syscalls
    > is going to mean that the threadlet context is fairly heavyweight, both
    > in memory and CPU/MMU state. This means that you can't pull it cheaply
    > over to whatever CPU core happened to process the device I/O that
    > delivered the data it wanted.
    []
    > Oh, and while I haven't written a kernel or an RDBMS, I have written
    > some fairly serious non-blocking I/O code (without resorting to
    > threads; one socket and thousands of independent userspace state
    > machines) and rewritten the plumbing of two fairly heavy-duty network
    > operations frameworks, one of them attached to a horrifically complex
    > GUI. And briefly, long ago, I made Transputers dance with Occam and
    > galaxies spin with PVM.

    transputers were (AFAIK) completely orthogonal to any today's x86 CPU
    architecture -- hardware parallelism, special programming language and
    technique to match this hardware. And they were chosen to work on Mars in
    mid-90th, while crowd wanted more stupid windows on cheap CPUs.

    > This gives me exactly zero credentials here, of course, but may suggest
    > to you that when I say something that seems naive, it's more likely
    > that I got the Linux-specific lingo wrong. That, or I'm _actively_
    > stupid. :-)

    Thus, i think, you are thinking mostly on hardware level, while it's
    longstanding software problem, i.e. to use x86 (:.

    Regards.
    --
    -o--=O`C
    #oo'L O
    <___=E M
    -
    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-22 20:45    [W:3.129 / U:0.276 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site