[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9bd88c1a-2124-c244-cdc3-5cf1bd4cce11@huaweicloud.com>
Date: Wed, 23 Jul 2025 10:07:07 +0800
From: Yu Kuai <yukuai1@...weicloud.com>
To: Damien Le Moal <dlemoal@...nel.org>, Yu Kuai <yukuai1@...weicloud.com>,
hare@...e.de, tj@...nel.org, josef@...icpanda.com, axboe@...nel.dk
Cc: cgroups@...r.kernel.org, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org, yi.zhang@...wei.com, yangerkun@...wei.com,
johnny.chenyi@...wei.com, "yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH 1/6] mq-deadline: switch to use high layer elevator lock
Hi,
在 2025/07/23 9:46, Damien Le Moal 写道:
> On 7/22/25 4:24 PM, Yu Kuai wrote:
>> From: Yu Kuai <yukuai3@...wei.com>
>>
>> Introduce a new spinlock in elevator_queue, and switch dd->lock to
>> use the new lock. There are no functional changes.
>>
>> Signed-off-by: Yu Kuai <yukuai3@...wei.com>
>> ---
>> block/elevator.c | 1 +
>> block/elevator.h | 4 ++--
>> block/mq-deadline.c | 57 ++++++++++++++++++++++-----------------------
>> 3 files changed, 31 insertions(+), 31 deletions(-)
>>
>> diff --git a/block/elevator.c b/block/elevator.c
>> index ab22542e6cf0..91df270d9d91 100644
>> --- a/block/elevator.c
>> +++ b/block/elevator.c
>> @@ -144,6 +144,7 @@ struct elevator_queue *elevator_alloc(struct request_queue *q,
>> eq->type = e;
>> kobject_init(&eq->kobj, &elv_ktype);
>> mutex_init(&eq->sysfs_lock);
>> + spin_lock_init(&eq->lock);
>> hash_init(eq->hash);
>>
>> return eq;
>> diff --git a/block/elevator.h b/block/elevator.h
>> index a07ce773a38f..cbbac4f7825c 100644
>> --- a/block/elevator.h
>> +++ b/block/elevator.h
>> @@ -110,12 +110,12 @@ struct request *elv_rqhash_find(struct request_queue *q, sector_t offset);
>> /*
>> * each queue has an elevator_queue associated with it
>> */
>> -struct elevator_queue
>> -{
>> +struct elevator_queue {
>> struct elevator_type *type;
>> void *elevator_data;
>> struct kobject kobj;
>> struct mutex sysfs_lock;
>> + spinlock_t lock;
>> unsigned long flags;
>> DECLARE_HASHTABLE(hash, ELV_HASH_BITS);
>> };
>
> I wonder if the above should not be its own patch, and the remaining below
> staying in this patch as that match exactly the commit title.
I think you mean *should be it's own patch*. I don't have preference and
I can do that in the next version :)
Thanks,
Kuai
Powered by blists - more mailing lists