Re: [RFC] aio: remove retry and cancel
On Tue, Oct 16, 2012 at 10:38:10AM -0700, Zach Brown wrote: Gadget cannot. The code has no control over when a request completes. Think of things like talking to a USB serial port or keyboard directly. Well, boo. That'd do it. The patch was crossing its fingers for the usb reqs to complete promptly :). Shoot. I was hoping this would fly, as Jens mentioned the current implementation of cancellation is really problematic w.r.t. performance. I've been floating another scheme for implementing cancellation without any overhead when it's not being used. Basically, we just need help from the allocator (need to be able to iterate over potentially allocated objects). I'll cook up an RFC patch, I think. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] aio: remove retry and cancel
On Mon, Oct 15, 2012 at 05:27:44PM -0700, Zach Brown wrote: The possibility of removing retry and cancelation came up a few times plumbers this year. I finally gave it a try. Removing retry is a good iea. It's of little value because retry happens in a kernel thread, not in the submitter's task. Getting rid of retry is probably a good idea. I'm ambivalent about removing cancelation. The code is almost never used, though, so I figured it'd be interesting to see if we can get away with getting rid of it. Canellation *cannot* be removed. If you remove cancellation, processes with outstanding ios at exit() time will never release their resources. -ben -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] aio: remove retry and cancel
Benjamin LaHaise b...@kvack.org writes: On Mon, Oct 15, 2012 at 05:27:44PM -0700, Zach Brown wrote: The possibility of removing retry and cancelation came up a few times plumbers this year. I finally gave it a try. Removing retry is a good iea. It's of little value because retry happens in a kernel thread, not in the submitter's task. Getting rid of retry is probably a good idea. I'm ambivalent about removing cancelation. The code is almost never used, though, so I figured it'd be interesting to see if we can get away with getting rid of it. Canellation *cannot* be removed. If you remove cancellation, processes with outstanding ios at exit() time will never release their resources. Please explain. wait_for_active_reqs will wait until all outstanding I/O has completed before returning. What resources do you think will be left? Cheers, Jeff -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] aio: remove retry and cancel
On Tue, Oct 16, 2012 at 12:33:42PM -0400, Jeff Moyer wrote: Benjamin LaHaise b...@kvack.org writes: Canellation *cannot* be removed. If you remove cancellation, processes with outstanding ios at exit() time will never release their resources. Please explain. wait_for_active_reqs will wait until all outstanding I/O has completed before returning. What resources do you think will be left? Not all IOs will complete within a bounded amount of time. Think of things like pipes, network send/receive, even the USB gadget code. It is not acceptable to block process exit until these IOs complete, as they may never complete. The aio core *must* support cancellation. That said, the how of such things can and should be improved. -- Thought is the essence of where you are now. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] aio: remove retry and cancel
Not all IOs will complete within a bounded amount of time. Think of things like pipes, network send/receive, even the USB gadget code. Yes, I know. That's the theoretical position. But reality doesn't match that view. People aren't using it. If the usb gadget code can do without then the actual users of aio can be made a wee bit faster without having to build cancel code without users to hammer on it. That's the argument behind the patch, anyway. I'm not particularly motivated either way on this. Just happy to demonstrate the possibility :). - z -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] aio: remove retry and cancel
On Tue, Oct 16, 2012 at 10:00:54AM -0700, Zach Brown wrote: Not all IOs will complete within a bounded amount of time. Think of things like pipes, network send/receive, even the USB gadget code. Yes, I know. That's the theoretical position. But reality doesn't match that view. People aren't using it. If the But that's an issue of the lack of support for the functionality. The kernel doesn't implement the functionality for 99.99% of file descriptors, so of course it's not going to be used. If, as we were chatting about, other uses can be made possible by using a thread pool or some as yet undecided approach, it will be required. Let's address the lack of support issue before deprecating required parts of the API. Or make the case to rip everything out. usb gadget code can do without then the actual users of aio can be made a wee bit faster without having to build cancel code without users to hammer on it. Gadget cannot. The code has no control over when a request completes. Think of things like talking to a USB serial port or keyboard directly. Afaik it is getting used for USB direct access in a number of cases, which goes to show that if the functionality is implemented, people will use it. -ben -- Thought is the essence of where you are now. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] aio: remove retry and cancel
On 2012-10-16 19:15, Benjamin LaHaise wrote: On Tue, Oct 16, 2012 at 10:00:54AM -0700, Zach Brown wrote: Not all IOs will complete within a bounded amount of time. Think of things like pipes, network send/receive, even the USB gadget code. Yes, I know. That's the theoretical position. But reality doesn't match that view. People aren't using it. If the But that's an issue of the lack of support for the functionality. The kernel doesn't implement the functionality for 99.99% of file descriptors, so of course it's not going to be used. If, as we were chatting about, other uses can be made possible by using a thread pool or some as yet undecided approach, it will be required. Let's address the lack of support issue before deprecating required parts of the API. Or make the case to rip everything out. Come on, this has been the case for, what, 10 years? Or for however long that we've had this aio interface. I'd be happy just bypassing the cancel, in fact I did just that to actually make aio scale to any extent at all. But using the lack of a support as an argument to keep that interface is just a non-starter to begin with. It's clearly NEVER goint to get done. usb gadget code can do without then the actual users of aio can be made a wee bit faster without having to build cancel code without users to hammer on it. Gadget cannot. The code has no control over when a request completes. Think of things like talking to a USB serial port or keyboard directly. Afaik it is getting used for USB direct access in a number of cases, which goes to show that if the functionality is implemented, people will use it. IMHO, just bypassing the cancel bits for things that don't implement it (that is, anything but usb gadget) is trivial. It's part of the lots of low hanging fruit in aio. -- Jens Axboe -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] aio: remove retry and cancel
Gadget cannot. The code has no control over when a request completes. Think of things like talking to a USB serial port or keyboard directly. Well, boo. That'd do it. The patch was crossing its fingers for the usb reqs to complete promptly :). - z -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] aio: remove retry and cancel
On Tue, Oct 16, 2012 at 07:23:25PM +0200, Jens Axboe wrote: Let's address the lack of support issue before deprecating required parts of the API. Or make the case to rip everything out. Come on, this has been the case for, what, 10 years? Or for however long that we've had this aio interface. I fully conceed that nobody has done any real work on it for the last 9 years. The question of where to go from here is wide open. I'd be happy just bypassing the cancel, in fact I did just that to actually make aio scale to any extent at all. But using the lack of a support as an argument to keep that interface is just a non-starter to begin with. It's clearly NEVER goint to get done. That's not the argument I'm making. The argument I'm making is that any AIO API requires cancellation functionality for file descriptors that are not block based IO that completes within a bounded amount of time. Any replacement will have to address that issue to be a real solution to the problem. -ben -- Thought is the essence of where you are now. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] aio: remove retry and cancel
The possibility of removing retry and cancelation came up a few times plumbers this year. I finally gave it a try. Removing retry is a good iea. It's of little value because retry happens in a kernel thread, not in the submitter's task. I'm ambivalent about removing cancelation. The code is almost never used, though, so I figured it'd be interesting to see if we can get away with getting rid of it. I haven't tested this at all. It's food for thought. - z -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
