From owner-freebsd-hackers Thu Apr 22 9:25:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailer.syr.edu (mailer.syr.edu [128.230.18.29]) by hub.freebsd.org (Postfix) with ESMTP id 567991539E for ; Thu, 22 Apr 1999 09:25:40 -0700 (PDT) (envelope-from cmsedore@mailbox.syr.edu) Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.D2B16780@mailer.syr.edu>; Thu, 22 Apr 1999 12:22:47 -0400 Received: from localhost (cmsedore@localhost) by rodan.syr.edu (8.8.7/8.8.7) with SMTP id MAA13439; Thu, 22 Apr 1999 12:22:35 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: cmsedore owned process doing -bs Date: Thu, 22 Apr 1999 12:22:35 -0400 (EDT) From: Christopher Sedore X-Sender: cmsedore@rodan.syr.edu Reply-To: Christopher Sedore To: John-Mark Gurney Cc: hackers@FreeBSD.ORG Subject: Re: aio_suspend() functionality In-Reply-To: <19990421203437.35158@hydrogen.nike.efn.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 21 Apr 1999, John-Mark Gurney wrote: > Christopher Sedore scribbled this message on Apr 21: > > > Why would one care about this? If one were going to have hundreds (or > > thousands) of outstanding asynchronous IO requests, it isn't very > > I wish this was possible.. you can only queue 256 and have 32 active > at once right now... sounds like we need to LINT some more options for > this... It looks to me like you can just up the limits with sysctl, though it would be nice to be able to have config options too. > > This patch is against FreeBSD 3.1-STABLE It works in my testing, and > > is not entirely backwardly compatible with the old aio_suspend (it won't > > behave the same way if you pass in an array of all NULL pointers, > > otherwise it should be functionally equivalent). > > I've been trying to get Dyson's attention about aio too... there is > one major problem with the code that allows any user that can do aio > to panic the system... also it doesn't honor the FREAD flag on a > descriptor... if you have a descriptor open just for writing, you can > read from it with aio... It looks to me like specifying an aiocb that fails copyin to aio_read() causes a memory leak. Is this what you're referring to? > I have fixes for both of these bugs... but right now I don't have a > machine to do -current testing on, so I won't be able to throughly > be able to test the patches... I'd be willing to put up a web page with a full collection of aio patches available if you'd like to share off-line. > > The patch will generate a warning during compiling because the upper > > layers pointing to aio_suspend expect the array of pointers to be a const, > > and I deconstify it. > > we should find out what DG and bde think about this change... it is a > nice change, though we need to evaluate what it does to the standard.. > one thing we might look at is just using a new aio_sleep function that > provides this functionality... Another issue of concern to me: it appears that the AIO daemons do blocking io on the descriptors, so if I had lots of sockets (more than max_aio_procs) open with async operations pending, the first max_aio_procs async reads would block all the async operations until one read was successful. This seems to make the async io somewhat less useful. I've been looking into modifying aio_process to have it requeue aio operations on sockets that get EWOULDBLOCK back from the read/write into a "waiting" queue, and then using socket upcalls to move them back to the job queue when the underlying socket is ready for a read or write. One other modification I've been considering would be to change the behavior of _aio_queue when it can't create an additional proc because of resource limits. Right now it returns EAGAIN, but I was thinking that it should check to see if there are aio daemons already running, and if so, just queue the job for later. If not, then EAGAIN seems appropriate. -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message