Re: [PATCH 3/5] dm: support retrieving struct dm_target from struct dm_dev

[YangYang <yang.yang@vivo.com>]

On 2024/5/17 22:33, Benjamin Marzinski wrote:
> On Fri, May 17, 2024 at 03:48:49PM +0800, YangYang wrote:
>> On 2024/5/16 23:29, Benjamin Marzinski wrote:
>>> On Thu, May 16, 2024 at 09:55:53AM +0800, YangYang wrote:
>>>> On 2024/5/15 23:42, Benjamin Marzinski wrote:
>>>>> On Tue, May 14, 2024 at 05:04:42PM +0800, Yang Yang wrote:
> 
>>>>
>>>> If I understand correctly, you are suggesting to iterate through all the
>>>> targets, handling those with sends_pass_around_flush set, and skipping
>>>> those where sends_pass_around_flush is not set. I believe this approach
>>>> may result in some CPU wastage.
>>>>
>>>>     for i in {0..1023}; do
>>>>       echo $((8000*$i)) 8000 linear /dev/sda2 $((16384*$i))
>>>>     done | sudo dmsetup create example
>>>>
>>>> In this specific scenario, a single iteration of the loop is all that
>>>> is needed.
>>>
>>> It's just one iteration of the loop either way. You either loop through
>>> the targets or the devices.  It's true that if you have lots of targets
>>> all mapped to the same device, you would waste time looping through all
>>> the targets instead of looping through the devices.  But if you only had
>>> one striped target mapped to lots of devices, you would waste time
>>> looping through all of the devices instead of looping through the
>>> targets.
>>
>> Yes, I get your point. This patchset may make things even worse for
>> the striped target.
>> I am just curious, in what scenario is the "dm-strip" target mapped to
>> a large number of underlying devices from the same block device.
>>
> 
> I don't think anyone in the real world does create dm-stripe devices with a
> huge number of stripe table devices. My point was that it didn't seem
> obvious me that looping through the targets was a significant problem
> compared to looping through the devices.
> 
> At any rate, Mikulas's patch already does this optimally, even for
> targets like dm-stripe, so it doesn't really matter now.
> 
> -Ben
> 

Yeah. Thanks for the explanation and your patience.