Date: Fri, 12 Jul 2013 10:05:04 +0800 From: David Xu <davidxu@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Adrian Chadd <adrian@freebsd.org>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: hacking - aio_sendfile() Message-ID: <51DF6450.7050204@freebsd.org> In-Reply-To: <20130711061753.GK91021@kib.kiev.ua> References: <CAJ-Vmo=icr6bda%2BWMNUarc3WbdqJ%2BMdauX6kByxxdTx8oSovBg@mail.gmail.com> <20130711061753.GK91021@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51DF6450.7050204>