This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Testing Posix asynchronous I/O
- From: Mark Geisert <mark at maxrnd dot com>
- To: cygwin-developers at cygwin dot com
- Date: Tue, 12 Jun 2018 01:18:09 -0700
- Subject: Re: Testing Posix asynchronous I/O
- References: <Pine.BSF.4.63.1712120028330.31850@m0.truegem.net> <20171212140038.GA9044@calimero.vinschen.de> <468b9021-4540-3cc3-69c1-6fcfb1de347e@maxrnd.com> <20180320101058.GF2772@calimero.vinschen.de> <29a1cddf-8f36-db34-8b2d-fa77ee8bcca6@maxrnd.com> <20180403075717.GA31790@calimero.vinschen.de> <Pine.BSF.4.63.1804030155190.50960@m0.truegem.net> <31519efa-8b52-2ea5-ee62-d2a908708bc1@maxrnd.com>
Updating my previous post...
On Tue, 3 Apr 2018, Corinna Vinschen wrote:
Some testcase (here on cygwin-developers, not as patch) would be
nice, too.
I do have a couple already. One is a (fairly large) test app I have that times
various methods of copying the heap from one process to a child. AIO is one of
those methods. I could whittle that down to something using only AIO. And the
Linux man page for aio(7) has a sample program that can test AIO on something
other than disk files.
The man page sample program, which does a single aio_read() on each file/device
named in args, seems to work for all cases except the specific one demonstrated
there, which is more than one /dev/stdin. On Cygwin, satisfying the first
aio_read() causes the second to be satisfied with no input. On Linux, the
program waits for each aio_read() to be satisfied in sequence.
In addition to those two test programs, there's iozone. That supports AIO
operations but would need to be ported to Cygwin. IMNSHO iozone needs a -NG
re-write. It is 5 source files, no header files, and 1K of its 30K lines are
#ifdef's. And what it calls a Windows build is actually a Cygwin (32-bits)
build. But it's there if needed, modulo some work porting it.
I have ported iozone to 64-bit Cygwin (not re-written) and I can see it will be
very helpful in stress-testing the AIO code. At the moment I'm debugging an odd
strace message after many thousands of I/Os:
0 [sig] iozone 12248 wait_sig: garbled signal pipe data nb 176, sig 0
which seems to say the code is internally sending "signal 0", but there's no
obvious way that could be occurring.
The "heap transfer" program I mentioned earlier, heapxfer, allows me to specify
heap size and number of simultaneous AIOs. Simple cases, such as staying within
AIO_MAX AIOs, work fine. I recently finished debugging a testcase writing 1GB
of data to a file using 512 AIOs. So the first AIO_MAX AIOs launched as inline
AIOs, while the remainder were queued. Then as worker threads became available,
they launched inline AIOs themselves. Found a couple of nits but it's working now.
Most recently with heapxfer I've been testing aio_write()s of 2047MB in 2047
AIOs on my 2Core/4Thread system. Found and fixed another obscure buglet.
I will be AFK June 15..25 but wanted to post status since it's been a while
since my last posting. Comments welcome but in any case I'll keep testing.
Thanks & Regards,
..mark