Re: hacking - aio_sendfile()

From: David Xu <davidxu_at_freebsd.org>
Date: Fri, 12 Jul 2013 10:05:04 +0800
On 2013/07/11 14:17, Konstantin Belousov wrote:
> On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote:
>> Hiya,
>>
>> I've started writing an aio_sendfile() syscall.
>>
>> http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff
>>
>> Yes, the diff is against -HEAD and not stable/9.
>>
>> It's totally horrible, hackish and likely bad. I've only done some
>> very, very basic testing to ensure it actually works; i haven't at all
>> stress tested it out yet. It's also very naive - I'm not at all doing
>> any checks to see whether I can short-cut to do the aio there and
>> then; I'm always queuing the sendfile() op through the worker threads.
>> That's likely stupid and inefficient in a lot of cases, but it at
>> least gets the syscall up and working.
> Yes, it is naive, but for different reason.
>
> The kern_sendfile() is synchronous function, it only completes after
> the other end of the network communication allows it. This means
> that calling kern_sendfile() from the aio thread blocks the thread
> indefinitely by unbounded sleep.
>
> Your implementation easily causes exhaustion of the aio thread pool,
> blocking the whole aio subsystem. It is known that our aio does not work
> for sockets for the same reason. I object against adding more code with
> the same defect.
>
> Proper route seems to rewrite aio for sockets using the upcalls.  The same
> should be done for sendfile, if sendfile is given aio flavor.
>

Yes, current aio implementation is horrible, it only works for fast 
disk I/O, I think the thread pool size is enough to saturate disks,
but for socket or pipe I/O, it does not work well, the thread pool is
too easy to be exhausted.

I even think the support for socket and pipe in aio code should be
cut and thrown away, because you can always use kqueue + non-blocking
I/O.
Received on Fri Jul 12 2013 - 00:04:28 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:39 UTC