Messages in this thread | | | Date | Fri, 03 Oct 2014 12:39:20 -0600 | From | Jens Axboe <> | Subject | Re: [PATCH] aio: Fix return code of io_submit() (RFC) |
| |
On 2014-10-03 12:31, Kent Overstreet wrote: > On Fri, Oct 03, 2014 at 02:22:20PM -0400, Benjamin LaHaise wrote: >> On Fri, Oct 03, 2014 at 12:13:39PM -0600, Jens Axboe wrote: >>> How are applications supposed to deal with ENOMEM? I think the answer >>> here is that they can't, it would be a fatal condition. AIO must provide >>> isn't own guarantee of progress, with a mempool or similar. >> >> I'm not sure if using a mempool is appropriate for allocations that are >> driven by userland code. At least with an ENOMEM error, an application >> could free up some of the memory it allocated and possibly recover the >> system. > > I guess it's going to depend on the application... some applications really want > to always make forward progress (much like a lot of code in the kernel), so > they're going to want the mempool semantics and we in the kernel are in a much > better position to implement that correctly (think of all the applications that > are just going to sleep and retry on -ENOMEM).
Precisely, there's no real way to do that in the application. Especially if it has no pending IO it can just wait on, it'll be a sleep and retry thing
> we kind of want another flag in the syscall args that's the moral equivalent of > MSG_DONTWAIT but for memory allocations; it'd translate into "mempool + > GFP_KERNEL, or GFP_NOWAIT".
We do...
> not that I'm actually going to implement that :)
It's worth keeping in mind for if we do extend the API for some reason.
-- Jens Axboe
| |