[Updated on 2006-08-09] Re: My Linux AIO Implementation Calling for Test

[Intron]

Download: http://ftp.intron.ac/tmp/linux_aio-20060809.tar.bz2

Updated files:

-rw-r--r--  1 root  wheel  33841  8  9 20:59 linux_aio.c
-rw-r--r--  1 root  wheel   2891  8  9 16:37 linux_aio.h
-rw-r--r--  1 root  wheel   4199  8  9 19:36 readme.txt
-rw-r--r--  1 root  wheel   1139  8  8 23:36 syscalls.master.diff
-rwxr-xr-x  1 root  wheel  46412  8  9 20:55 testaio
-rw-r--r--  1 root  wheel   3742  8  9 20:59 testaio.c

Alexander Leidinger wrote:

> 
> There are some style problems:
>  - macros do not have to end with a ';'
>  - lines with more than 80 characters (so far they can be changed to
>    continue on the next line or some similar modifications)
>  - between switch/if/while/... and the '(' should be a space
>  - code which isn't used should be disabled with preprocessor
>    directives, not with comments
>  - '}' and '{' should be on the same line as the "else"
>  - maybe more...

I have modified my code as you advised.

> 
> And some code problems:
>  - "Both User Space and Kernel Memory Leaked!" doesn't look very
>    encouraging, what's the reason for this? How often can this occour
>    and when?

Actually I once talked about this problem of memory leak to you and
another German discussant around two months ago. FreeBSD's native aio(4)
is much more powerful than Linux AIO. But there's a limitation in
FreeBSD aio(4): some I/O operation cannot be cancelled after being
started and before completion.

Lines 208-216 in /sys/kern/vfs_aio.c read:

/*
  * Current, there is only two backends: BIO and generic file I/O.
  * socket I/O is served by generic file I/O, this is not a good idea, since
  * disk file I/O and any other types without O_NONBLOCK flag can block daemon
  * threads, if there is no thread to serve socket I/O, the socket I/O will be
  * delayed too long or starved, we should create some threads dedicated to
  * sockets to do non-blocking I/O, same for pipe and fifo, for these I/O
  * systems we really need non-blocking interface, fiddling O_NONBLOCK in file
  * structure is not safe because there is race between userland and aio
  * daemons.
  */

In my code, once these types of AIO requests are submitted to FreeBSD's
native aio(4), I can neither cancel them at once, nor destroy all related
data structures both in user space and in kernel.

So far I don't how to avoid this type of memory leak.
1. Prohibit those types of IO requests?
2. Wait for their completion even for minutes?

On the other hand, if my linux_io_destroy() reports EAGAIN/EWOULDBLOCK
to userland application, some GNU/Linux applications may exit abnormally.
Because Linux io_destroy(2) will not throw the exception EAGAIN or
EWOULDBLOCK.

>  - please use the l_int, l_uint, ... types instead of plain int,
>    unsigned, ... so that it can be used on amd64 too (the linuxolator
>    runs in "32bit mode" there, so a 64bit long will break there)

I have modified my code (including "syscalls.master.diff") as you advised.

> 
> Maybe I will find some more stuff later...
> 
> Bye,
> Alexander.
> 
> -- 
> The wages of sin is death, but so is the salary of virtue, and at least the evil get to go home early on Fridays.
> (Witches Abroad)
> http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
> http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137

------------------------------------------------------------------------
                                                From Beijing, China