On Wed, 5 Nov 2003, Robert Watson wrote: > On Wed, 5 Nov 2003, Igor Sysoev wrote: > > > On Wed, 5 Nov 2003, Robert Watson wrote: > > > > > On Wed, 5 Nov 2003, Igor Sysoev wrote: > > > > > > > As to worker kthreads I think it's better to queue aio operation as it > > > > was made in src/sys/kern/vfs_aio.c:aio_qphysio(). > > > > > > One of the things that worries me about the proposal to use kernel worker > > > threads to perform the I/O is that this can place a fairly low upper bound > > > on effective parallelism, unless the kernel threads themselves can issue > > > the I/O's asynchronously. In the network stack itself, we are event and > > > queue driven without blocking--if we can maintain the apparent semantics > > > to the application, it would be very nice to be able to handle that at the > > > socket layer itself. I.e., not waste a thread + stack per "in-progress" > > > operation, and instead have a worker or two that simply propel operations > > > up and down the stack (similar to geom_up and geom_down). > > > > As far as I understand src/sys/kern/vfs_aio.c:aio_qphysio() (that > > handles AIO on raw disks) does not use kthreads and simply queues > > operations. > > I think it sounds like we're actually agreeing with each other.
Yes. > Currently, AIO does use threads for non-character devices, so in the > socket case it will be using a worker thread. Yes, current AIO implementation uses worker threads for regular files. But I suggest not to use AIO code for sendfile() to read a file page. I suggest to use BUF_STRATEGY() like aio_qphysio() does. Is it possible to read a regular file page using BUF_STRATEGY() ? Igor Sysoev http://sysoev.ru/en/ _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
