lkml.org 
[lkml]   [2007]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 2 of 4] Introduce i386 fibril scheduling
Date
> But really, being a scheduler guy i was much more concerned about the
> duplication and problems caused by the fibril concept itself - which
> duplication and complexity makes up 80% of Zach's submitted patchset.
> For example this bit:
>
> [PATCH 3 of 4] Teach paths to wake a specific void * target
>
> would totally go away if we used kernel threads for this.

Uh, would it? Are you talking about handing off the *task_struct*
that it was submitted under to each worker thread that inherits the
stack?

I guess I hadn't considered going that far. I had somehow
constructed a block in my mind that we couldn't release the
task_struct from the submitting task. But maybe we can be clever
enough with the task_struct updating that userspace wouldn't notice a
significant change.

Hmm.

> i totally agree that the API /should/ be the main focus - but i didnt
> pick the topic and most of the patchset's current size is due to
> the IMO
> avoidable fibril concept.

I, too, totally agree. I didn't even approach the subject for
exactly the reason you allude to -- I wanted to get the hard parts of
the kernel side right first.

> regarding the API, i dont really agree with the current form and
> design
> of Zach's interface.

Haha, well, yes, of course. You couldn't have thought that the dirt-
stupid sys_asys_wait_for_completion() was anything more than simple
scaffolding to test the kernel bits.

> fundamentally, the basic entity of this thing should be a /system
> call/,
> not the artificial fibril thing:
>
> +struct asys_call {
> + struct asys_result *result;
> + struct fibril fibril;
> +};

You picked a weird struct to highlight here. struct asys_input seems
more related to the stuff you go on to discuss below. This asys_call
struct is a relatively irrelevant internal detail of how
asys_teardown_stack() gets from a fibril to the pre-allocated
completion state once the call has returned.

> The normal and most optimal workflow should be a user-space ring-
> buffer
> of these constant-size struct async_syscall entries:
>
> struct async_syscall ringbuffer[1024];
>
> LIST_HEAD(submitted);
> LIST_HEAD(pending);
> LIST_HEAD(completed);

I strongly disagree here, and I'm hoping you're not as keen on this
now -- your reply to Matt gives me hope.

As mentioned, that they complete out-of-order leads, at least, to
having separate submission and completion rings. I'm not sure a
submission ring makes any sense given the goal of processing the
calls in submission and only creating threads if it blocks. A simple
copy of an array of these input structs sounds fine to me.

When I think about the completion side I tend to hope we can end up
with something like what VJ talked about in his net channels work.
producer/consumer rings with head and tail pointers in different
cache lines. AFAIK the kevent work has headed in that direction, but
I haven't kept up. Uli has certainly mentioned it in his 'ec' (event
channels) proposals.

The posix AIO list completion and, sadly, signals on completion need
to be considered, too.

Honestly, though, I'm not worried about this part. We'll easily come
to an agreement. I'm just not going to distract myself with it until
we're happy with the scheduler side.

> Looks like we can hit many birds with this single stone: AIO, vectored
> syscalls, finegrained system-call parallelism. Hm?

Hmm, indeed. Some flags could let userspace tell the kernel not to
bother with all this threading/concurrency/aio nonsense and just
issue them serially. It'll sound nuts in these days of cheap
syscalls and vsyscall helpers, but some Oracle folks might love this
for issuing a gettimeofday() pair around syscalls they want to profile.

I hadn't considered that as a potential property of this interface.

- z
-
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-05 18:47    [W:0.205 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site