ok, i think i noticed another misunderstanding. The kernel thread
based
scheme i'm suggesting would /not/ 'switch' to another kernel thread in
the cached case, by default. It would just execute in the original
context (as if it were a synchronous syscall), and the switch to a
kernel thread from the pool would only occur /if/ the context is about
to block. (this 'switch' thing would be done by the scheduler)
Yeah, this is what I imagined when you described doing this with
threads instead of these 'fibril' things.
It sounds like you're suggesting that we keep the 1:1 relationship
between task_struct and thread_info. That would avoid the risks that
the current fibril approach brings. It insists that all of
task_struct is shared between concurrent fibrils (even if only
between blocking points). As I understand what Ingo is suggesting,
we'd instead only explicitly share the fields that we migrate (copy
or get a reference) as we move the stack from the submitting
task_struct to a waiting_task struct as the submission blocks.
We trade initial effort to make things safe in the presence of
universal sharing for effort to introduce sharing as people notice
deficient behaviour. If that's the way we prefer to go, I'm cool
with that. I might have gone slightly nuts in preferring *identical*
sync and async behaviour.
The fast path would look almost identical to the existing fibril
switch. We'd just have a few more fields to sync up between the two
task_structs.
Ingo, am I getting this right? This sounds pretty straight forward
to prototype from the current patches. I can certainly give it a try.
it's quite cheap to 'flip' it to under any arbitrary user-space
context:
change its thread_info->task pointer to the user-space context's task
struct, copy the mm pointer, the fs pointer to the "worker thread",
switch the thread_info, update ptregs - done. Hm?
Or maybe you're talking about having concurrent executing
thread_info's pointing to the user-space submitting task_struct?
That really does sound like the current fibril approach, with even
more sharing of thread_info's that might be executing on other cpus?
Either way, I want to give it a try. If we can measure it performing
reasonably in the cached case then I think everyone's happy?
is not part of the signal set. (Although it might make sense to make
such async syscalls interruptible, just like any syscall.)
I think we all agree that they have to be interruptible by now,
right? If for no other reason than to interrupt pending poll with no
timeout, say, as the task exits..
The 'pool' of kernel threads doesnt even have to be per-task, it
can be
a natural per-CPU thing
Yeah, absolutely.
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
