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.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
