On 5/4/2020 9:12 AM, Jens Axboe wrote:
On 5/3/20 6:52 AM, Pavel Begunkov wrote:
On 30/04/2020 17:52, Jens Axboe wrote:
On 4/29/20 6:47 PM, Bijan Mottahedeh wrote:
Use ctx->fallback_req address for test_and_set_bit_lock() and
clear_bit_unlock().
Thanks, applied.
How about getting rid of it? As once was fairly noticed, we're screwed in many
other ways in case of OOM. Otherwise we at least need to make async context
allocation more resilient.
Not sure how best to handle it, it really sucks to have things fall apart
under high memory pressure, a condition that isn't that rare in production
systems. But as you say, it's only a half measure currently. We could have
the fallback request have req->io already allocated, though. That would
provide what we need for guaranteed forward progress, even in the presence
of OOM conditions.
A somewhat related question, would it make sense to have (configurable)
pre-allocated requests, to be used first if low latency is a priority
for a ring, or would the allocation overhead be negligible compared to
the actual I/O? This would be the flip side of fallback in a sense.
Thanks.
--bijan
--bijan
