DragonFly BSD
DragonFly kernel List (threaded) for 2003-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: userapi: signals

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 22 Jul 2003 10:17:15 -0700 (PDT)

:>    I'm not sure how much kernel threading applies to user threading.  Kernel
:>    threads are more sensitive to memory issues since there is only one 
:>    KVM address space and very little of it is pageable.
:That doesn't mean the one can't be modelled on the other, and there's a
:lot of reasons (including the ease of developing code that can run in
:both contexts) for modelling the one on the other.

   Oh, absolutely.  In fact I expect it ought to be possible to transplant
   most of the LWKT scheduler and LWKT messaging code to userland.

:>:	2b. A userland thread will never be moved to another CPU, and will 
:>:never be preempted by a non-signal thread.
:>    No.  In userland anything can happen.  The system is free to interrupt
:>    a userland program and migrate it to another cpu at any time.
:OK, for "CPU" read "virtual CPU". It's going to continue to share its
:kernel-managed execution context with the same set of threads, and
:within that context it won't be preempted unless a signal (the user
:level equivalent of an interrupt) occurs.

    Correct.  So the same abstractions we use in the kernel could be used
    in userland.  i.e. messaging between (rforked) processes, use of a
    'critical section' to protect per-(rfork)-cpu data, localized scheduling,
    and so forth.

:>    To another abstracted cpu (rfork).  Yes, though perhaps all it really
:>    needs to do is write() to a communications pipe that goes to the target
:>    (abstracted) cpu.  Thus this sort of operation would become more
:>    efficient under heavier loads.
:That write() is probably going to require a context switch through kernel
:mode to complete (if only to avoid race conditions), though like an IPI that
:context switch can be deferred if there's other work still to do in the current
:rfork()ed context, and bundled up with other work.
:If you have a consistent view of memory AND you know for sure the other
:thread's on another CPU you could probably get away with something
:like a spinlock (but if it's on the same CPU that could get expensive :) ).

    There are lots of ways to do this.  Perhaps the use of a pipe just for
    notification (e.g. just write one byte and read-drain), or a SysV
    semaphore, and transfer the messages directly via shared memory.

    The kernel uses a very interesting lockless cross bar mechanism to
    handle the IPI messaging between cpus.  See lwkt_send_ipiq() in
    kern/lwkt_thread.c.  That sort of mechanism could easily be applied
    to the userland scheduler as well for communication between cpus.

:>    Right.  In fact, we could probably compile most of the LWKT subsystem
:>    separately as part of the userland scheduler. 
:Whether it's the same code or not (and that would be cool) it has a lot of
:the same restrictions and responsibilities.
:Do this right, and the UNIX system call emulator itself could run in the
:kernel. Which opens up all kinds of interesting possibilities. It would
:probably become possible to port dragonfly to hardware that doesn't
:even have an MMU, like an Amiga 1000 or Palm III.

    I really want the syscall emulator to run in usermode because the
    syscall emulator has so many interesting possibilities that only
    the ease of userland development (not crashing the system :-)) is
    capable of realizing them all.  Also because the emulation layer can
    become quite complex, especially considering linux and sysv (which I
    want to move out of the kernel and into the emulation layer), and 
    moving it out of the kernel would make the system more stable without
    costing us any performance.

					Matthew Dillon 

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]