Re: [PATCH] the dm-loop target

[Ming Lei <ming.lei@redhat.com>]

On Tue, Mar 18, 2025 at 12:57:17AM -0700, Christoph Hellwig wrote:
> On Tue, Mar 18, 2025 at 03:27:48PM +1100, Dave Chinner wrote:
> > Yes, NOWAIT may then add an incremental performance improvement on
> > top for optimal layout cases, but I'm still not yet convinced that
> > it is a generally applicable loop device optimisation that everyone
> > wants to always enable due to the potential for 100% NOWAIT
> > submission failure on any given loop device.....

NOWAIT failure can be avoided actually:

https://lore.kernel.org/linux-block/20250314021148.3081954-6-ming.lei@redhat.com/

> 
> Yes, I think this is a really good first step:
> 
> 1) switch loop to use a per-command work_item unconditionally, which also
>    has the nice effect that it cleans up the horrible mess of the
>    per-blkcg workers.  (note that this is what the nvmet file backend has

It could be worse to take per-command work, because IO handling crosses
all system wq worker contexts.

>    always done with good result)

per-command work does burn lots of CPU unnecessarily, it isn't good for
use case of container, and it can not perform as well as NOWAIT.

> 2) look into NOWAIT submission, especially for reads this should be
>    a clear winner and probaby done unconditionally.  For writes it
>    might be a bit of a tradeoff if we expect the writes to allocate
>    a lot, so we might want some kind of tunable for it.

It is a winner for over-write too.

WRITE with allocation can be kept to submit from wq context, see my
patchset V2.


Thanks,
Ming