Jens Axboe wrote:

> Looks good, I've been toying with something very similar for a long time
> myself.
> 
> The unplug change is a no-brainer.

Yep - I may have even stolen it from you (or someone) from a patch
which had been forgotten. I can't remember for sure, but it is trivial
enough that anyone could come up with it if they noticed, so I won't
worry about attribution ;)

> The retry stuff i __make_request()
> will make no real difference on 'typical' hardware, when it was
> introduced in 2.4.x it was very useful on slower devices like dvd-rams.
> The batch wakeups should take care of this.
> 

OK cool, that was the main thing I was unsure of.

> The atomic-vs-blocking allocation should be tested. I'd really like it
> to be a "don't dive into the vm very much, just wait on the mempool"
> type allocation, so we are not at the mercy of long vm reclaim times
> hurting the latencies here.
> 

Ahh yes I forgot it was backing it with a mempool. The problem I see
with that is that GFP_ATOMIC allocations eat into the mm's "atomic
reserve" pool (main use: networking), which would be nice not to.

So long as we are sure that we'll *eventually* fall back to the mempool,
it should be OK (but I still agree should have testing) - that isn't
entirely clear though, because the page allocator infinitely loops on
small allocations unless __GFP_NORETRY is set.

Andrew - tell me I'm missing something?