lkml.org 
[lkml]   [2003]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Scheduler activations (IIRC) question
Arjan van de Ven wrote:
> > > Oh. You just want to dispatch N syscalls from one entry to the kernel?
> >
> > No, not at all. I want to schedule cooperative state machines in
> > userspace, in the classical select-loop style, but without idling the
> > CPU when there's unpredictable blocking on disk I/O.
>
> eg you want AIO stat().....

Plus AIO link(), unlink(), rename(), open() (especially open),
msync(), mlock(), mmap(), sendfile(), readdir(), readlink(), ioctl()
and a few more.

These are too complicated to re-implement using explicit state
machines in the kernel. That would require rewriting huge amounts of
code in all the individual filesystems. You could never really trust
all the blocking corner cases were removed - fetching metadata,
reading directory blocks, allocating memory etc.

That's why the kernel would implement AIO stat() et al. by creating a
set of task contexts to handle queue of these requests.

Even that's at least as complicated as doing it in userspace.

Also with current AIO interface there will always be operations things
that it doesn't support, while the scheduler method works with
anything that blocks, including VM paging.

That said, a generalised "async syscall" interface would be very nice.
It could automatically dispatch things which AIO supports using AIO,
and everything else using task contexts.

-- Jamie

-
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: 2005-03-22 13:47    [W:0.079 / U:5.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site