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