Re: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support

On Tue, Feb 13, 2007 at 05:56:42PM +0100, Ingo Molnar (mingo@xxxxxxx) wrote:

* Benjamin LaHaise <bcrl@xxxxxxxxx> wrote:

Open issues:

Let me add some more

Also: FPU state (especially important with the FPU and SSE memory copy
variants), segment register bases on x86-64, interaction with
set_fs()...

agreed - i'll fix this. But i can see no big conceptual issue here -
these resources are all attached to the user context, and that doesnt
change upon an 'async context-switch'. So it's "only" a matter of
properly separating the user execution context from the kernel execution
context. The hardest bit was getting the ptregs details right - the
FPU/SSE state is pretty much async already (in the hardware too) and
isnt even touched by any of these codepaths.

Good work, Ingo.

I have not received first mail with announcement yet, so I will place
my thoughts here if you do not mind.

First one is per-thread data like TID. What about TLS related kernel
data (is non-exec stack property stored in TLS block or in kernel)?
Should it be copied with regs too (or better introduce new clone flag,
which would force that info copy)?

Btw, does SSE?/MMX?/call-it-yourself really saved on context switch?
As far as I can see no syscalls (and kernel at all) use that registers.

Another one is more global AIO question - while this approach IMHO
outperforms micro-thread design (Zach and Linus created really good
starting points, but they too have fundamental limiting factor), it
still has a problem - syscall blocks and the same thread thus is not
allowed to continue execution and fill the pipe - so what if system
issues thousands of requests and there are only tens of working thread
at most. What Tux did, as far as I recall, (and some other similar
state machines do :) was to break blocking syscall issues and return
to the next execution entity (next syslet or atom). Is it possible to
extend exactly this state machine and interface to allow that (so that
some other state machine implementations would not continue its life :)?

Ingo

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

Relevant Pages

  • Re: USB2 + kdb support (UMASS disk dump + USB keyboard)
    ... Instead I want to enforce normal running mode where USB and timer callbacks are handled like normal when in the kernel debugger. ... When the CPU is in the debugger and is asking for USB devices to be polled, is there a way to get the USB threads running again so that callbacks can be handled? ... From within callout handlers and task queue execution environments. ... While in DDB, in general, no further kernel execution is permitted, and we disable interrupts and IPI all CPUs to ensure that is the case. ...
    (freebsd-current)
  • Re: [tip:perfcounters/core] perf_counter: x86: Fix call-chain support to use NMI-safe method
    ... See the numbers in the other mail: about 33 million pagefaults ... speed up the kernel entry and exit, the few tens of cycles we ... Execution of a newly forked/exec'd process instruction causes a fault. ...
    (Linux-Kernel)
  • Re: AT_EXECFN not useful
    ... have to canonicalize the path (call realpath etc). ... AT_EXECFN also may have an advantage when the kernel ... Perhaps glibc cannot verify the value, so that may be a reason to avoid ... the value in the case of suid/sgid execution. ...
    (Linux-Kernel)
  • Re: linux context switching
    ... the process is excuted in a kernel mode, at this momnet is there context ... all registers are saved on the stack. ... interrupt handler is excuted ...
    (comp.os.linux.development.system)
  • Re: [Full-disclosure] [Dailydave] What RedHat doesnt want you to know about ExecShield (without
    ... SE Linux has nothing to do with buffer overflows besides checking that the ... highest executable mapping in the address space is executable. ... The mapping addresses are a policy of the kernel. ... Until the kernel address space has no execution permission ...
    (Full-Disclosure)