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 [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]
