Date: Thu, 22 Apr 1999 12:22:35 -0400 (EDT) From: Christopher Sedore <cmsedore@mailbox.syr.edu> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: hackers@FreeBSD.ORG Subject: Re: aio_suspend() functionality Message-ID: <Pine.SOL.3.95.990422104408.5797D-100000@rodan.syr.edu> In-Reply-To: <19990421203437.35158@hydrogen.nike.efn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.3.95.990422104408.5797D-100000>