Received-SPF: pass (google.com: domain of linux-kernel+bounces-40472-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Fri, 26 Jan 2024 19:09:31 +0100 (CET)
From: Mikulas Patocka <mpatocka@redhat.com>
To: Hannes Reinecke <hare@suse.de>
cc: Damien Le Moal <dlemoal@kernel.org>, 
    Linus Torvalds <torvalds@linux-foundation.org>, Tejun Heo <tj@kernel.org>, 
    Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org, 
    dm-devel@lists.linux.dev, Mike Snitzer <msnitzer@redhat.com>, 
    Ignat Korchagin <ignat@cloudflare.com>, 
    Damien Le Moal <damien.lemoal@wdc.com>, Hou Tao <houtao1@huawei.com>, 
    Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH] softirq: fix memory corruption when freeing
 tasklet_struct
In-Reply-To: <d390d7ee-f142-44d3-822a-87949e14608b@suse.de>
Message-ID: <d01a8554-10dd-1968-c9b0-f9ff16e6ac4@redhat.com>
References: <82b964f0-c2c8-a2c6-5b1f-f3145dc2c8e5@redhat.com> <CAHk-=wjDW53w4-YcSmgKC5RruiRLHmJ1sXeYdp_ZgVoBw=5byA@mail.gmail.com> <586ca4dd-f191-9ada-1bc3-e5672f17f7c@redhat.com> <5e2b5f23-94f0-4bf0-80a6-48380c7dc730@kernel.org>
 <d390d7ee-f142-44d3-822a-87949e14608b@suse.de>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII


On Fri, 26 Jan 2024, Hannes Reinecke wrote:

> Oh, it's this time of the year again?
> (This topic regularly comes up ...)
> 
> The reason is not that it will disable dm-multipath (Mike Snitzer put in
> bio-based multipathing as an additional code path); the reason is that
> dm-multipath performance will suffer when you remove request-based DM.

Is there some benchmark that says how much will it suffer?

> DM-multipath schedules based on request (if you use the request-based
> interface) or bios (if you use the bio-based interface).
> Any merge decision is typically done by the block layer when combining bios
> into requests; and you can only merge bios if the bvecs are adjacent.
> So if you use bio-based multipathing you will spread sequential bios
> across all paths, leaving the block layer unable to merge requests.

The same problem exists in raid1 and there's a function read_balance that 
solves it. If the starting sector of a new bio matches the ending sector 
of a previous bio, then submit it for the same device.

> For request based multipathing the requests are already fully-formed,
> and scheduling across paths does not change them.
> Things are slightly better with multi-page bvecs nowadays, but the
> overall picture still stands.
> 
> Another thing is timeouts; bios don't do timeouts, so a bio can run
> for an arbitrary time with no chance of interrupting it.
> Requests do have a timeout, and will be aborted from the driver when
> the timeout is hit.
> Seeing that 99% of all I/O issues I've seen _are_ timeouts it becomes
> a crucial feature if you want dm-multipath to control failover time.

You can set timeout of the underlying physical devices.

> Cheers,
> 
> Hannes

Mikulas