Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 5 Mar 1999 00:24:07 -0500 (EST)
From:      "John S. Dyson" <dyson@iquest.net>
To:        tlambert@primenet.com (Terry Lambert)
Cc:        dyson@iquest.net, tlambert@primenet.com, dick@tar.com, jplevyak@inktomi.com, hackers@FreeBSD.ORG
Subject:   Re: lockf and kernel threads
Message-ID:  <199903050524.AAA20441@y.dyson.net>
In-Reply-To: <199903050344.UAA24997@usr01.primenet.com> from Terry Lambert at "Mar 5, 99 03:44:32 am"

next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert said:
> > > IMO, the Linux threading, in particular, and the POSIX aio and thread
> > > interfaces, in general, represents a bunch of ill-thought-out hacks
> > > on hacks by the respective Linux and POSIX responsible persons.  The
> > > Linux hacks were by people who didn't know better, and the POSIX
> > > hacks were political by people who did know better, but didn't have
> > > the courage of their convictions.  It is time for some considered
> > > design.
> >
> > The AIO api has to be implemented for legitimacy, and likewise the
> > threading.  In fact, the AIO API is quite useful.
> 
> It doesn't have to be implemented in kernel space.
>
Kernel AIO is as trivial (and practically as fast) for async raw I/O as
for normal raw I/O.  The expedient implementation of AIO that I put
together is just that, and a super efficient version for other types
of file descriptors is possible, and not really hard to do.

By doing threading type things, without a proper kernel infrastructure
(which the BSD and Linux kernels don't have), all that is happening is
to increase overheads.  Don't thread something that it is just a fun
exercise to do so.  The stack context in the kernel is just plain
evil.

The BSD kernel is meant to provide a UNIX API, and implementing the
UNIX API should be done in an efficient way, which often means to
minimize the user/kernel transitions.  AIO isn't really that hard
to do in the kernel, and should be done there.  Sure, there are probably
things that shouldn't be in the kernel.  Much of the complexity that
is in the existing AIO code is the thread emulation of AIO, and will
reside somewhere.  If it is done in user-mode, it will require lots
more transitions.

Remember the AIO package can do LOTS of requests per system call.

Unnecessarily doing things with threads on the BSD kernel is really
a no-no, and is basically a way of spending CPU.  The AIO code should
be implemented like it is for raw devices -- a clean and efficient
way.  Lots of I/O requests can be processed with only one I/O
user-kernel-user request given the current implementation.  With
promiscuous knowledge, it is even possible to minimize system calls
(and do some work in user space) with the current code.  Some of the
stubs have experimental versions on my machine that support such a
bypass.

-- 
John                  | Never try to teach a pig to sing,
dyson@iquest.net      | it makes one look stupid
jdyson@nc.com         | and it irritates the pig.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903050524.AAA20441>