[lkml]   [2007]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2 of 4] Introduce i386 fibril scheduling
> 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

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-02-05 18:05    [W:0.250 / U:1.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site