I'm trying to finish my modifications to the aio code, and have a few questions I'm hoping someone would be willing to take time to answer.
First, I have modified the code to queue aio requests for sockets differently. If the socket is soreadable/writeable, the operation happens as before. If not, the aio op is queued seperately. This is where the complexity begins. When sowakeup is called, it checks to see if the socket is waiting on async operations and upcalls into a new routine to move the queued operations back to the main job queue. This means that all the manipulations of that queue (a TAILQ) must be protected at by splnet()/splx() blocks. There are some number of these manipulations. My question is: should I create an alternate queue to hold aio operations for now-ready sockets, so that I don't have to splnet()/splx() every manipulation of the main queue? How expensive is splnet? Note that there's already a separate queue for block io routines, but that makes more sense because they're handled in a completely different way. Second, I ended up having to back out some code written to do reads in the upcall because I was generating a panic every time that an upcall happened when my process wasn't curproc (uio_move was generating a trap because curpcb? wasn't pointing where/describing what it thought it should). I'm wondering if I can do i/o on a socket descriptor (using a struct uio) during an upcall for a socket that I know to be readable when I don't know that that process is curproc. Doing the read in the upcall offers a significant increase in performance, so its a nontrivial win. Finally, a stylistic question. I'm unsure what accepted/able practice for including headers across kernel source files. I modified the socket structure (socketvar.h) to include a TAILQ_HEAD for aio operations waiting on that socket. This TAILQ_HEAD points to struct aiocblist. I moved that structure from vfs_aio.c to sys/aio.h and then included sys/aio.h in uipc_socket.c. Is this the correct thing to do? Sorry for the basic questions, but I'd like to see this work get committed, and I understand that means that it needs to be done "right" for that to happen. -Chris To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
