mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: John Garry <john.g.garry@oracle.com>
To: Jason Yan <yanaijie@huawei.com>,
	Damien Le Moal <dlemoal@kernel.org>,
	Yihang Li <liyihang9@huawei.com>,
	jejb@linux.ibm.com, martin.petersen@oracle.com,
	chenxiang66@hisilicon.com
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linuxarm@huawei.com, prime.zeng@huawei.com,
	yangxingui@huawei.com
Subject: Re: [PATCH] scsi: libsas: Add SMP request allocation handler callback
Date: Mon, 25 Mar 2024 15:10:07 +0000	[thread overview]
Message-ID: <3ea54627-339f-4d19-896d-5843a8b9e55e@oracle.com> (raw)
In-Reply-To: <e7612e81-dc44-7bc6-3bd2-0b71367408ec@huawei.com>

On 25/03/2024 14:21, Jason Yan wrote:
> On 2024/3/25 22:03, Damien Le Moal wrote:
>> On 3/25/24 22:17, Yihang Li wrote:
>>> This series [1] reducing the kmalloc() minimum alignment on arm64 to 8
>>> (from 128).
>>
>> And ? What is the point you are trying to convey here ?
>>
>>> The hisi_sas has special requirements on the memory address alignment
>>> (must be 16-byte-aligned) of the command request frame, so add a SMP
>>> request allocation callback and fill it in for the hisi_sas driver.
>>
>> 128 is aligned to 16. So what is the problem you are trying to solve 
>> here ?
>> Can you clarify ? I suspect this is all about memory allocation 
>> optimization ?
> 
> After series [1] been merged, kmalloc is 8-byte-aligned, however 
> hisi_sas hardware needs 16-byte-aligned. That's the problem.
> 
>>
>>>
>>> Link: 
>>> https://urldefense.com/v3/__https://lkml.kernel.org/r/20230612153201.554742-1-catalin.marinas@arm.com__;!!ACWV5N9M2RV99hQ!L85qzmByNbkBbZByXKuNMAhvt8wxKPCsogKt3Pgn93DTkzfc54jA3of5XL8oEDDDDTMU1OtghdKiLZdKe5ub$  [1]
>>> Signed-off-by: Yihang Li <liyihang9@huawei.com>
>>> ---
>>>   drivers/scsi/hisi_sas/hisi_sas_main.c | 14 ++++++++++++
>>>   drivers/scsi/libsas/sas_expander.c    | 31 ++++++++++++++++++---------
>>>   include/scsi/libsas.h                 |  3 +++
>>>   3 files changed, 38 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
>>> b/drivers/scsi/hisi_sas/hisi_sas_main.c
>>> index 097dfe4b620d..40329558d435 100644
>>> --- a/drivers/scsi/hisi_sas/hisi_sas_main.c
>>> +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
>>> @@ -2031,6 +2031,19 @@ static int hisi_sas_write_gpio(struct 
>>> sas_ha_struct *sha, u8 reg_type,
>>>                   reg_index, reg_count, write_data);
>>>   }
>>> +static void *hisi_sas_alloc_smp_req(int size)
>>> +{
>>> +    u8 *p;
>>> +
>>> +    /* The address must be 16-byte-aligned. */
>>
>> ARCH_DMA_MINALIGN is not always 16, right ?
>>
>>> +    size = ALIGN(size, ARCH_DMA_MINALIGN);
>>> +    p = kzalloc(size, GFP_KERNEL);

Please make it clear that kmalloc() will return a naturally-aligned 
memory for power-of-2 sizes, and so ensuring that size is roundup to 16B 
will give a data which is aligned to 16B

>>> +    if (p)
>>> +        p[0] = SMP_REQUEST;
>>> +
>>> +    return p;
>>> +}
>>> +
>>>   static void hisi_sas_phy_disconnected(struct hisi_sas_phy *phy)
>>>   {
>>>       struct asd_sas_phy *sas_phy = &phy->sas_phy;
>>> @@ -2130,6 +2143,7 @@ static struct sas_domain_function_template 
>>> hisi_sas_transport_ops = {
>>>       .lldd_write_gpio    = hisi_sas_write_gpio,
>>>       .lldd_tmf_aborted    = hisi_sas_tmf_aborted,
>>>       .lldd_abort_timeout    = hisi_sas_internal_abort_timeout,
>>> +    .lldd_alloc_smp_req    = hisi_sas_alloc_smp_req,
>>
>> Why this complexity ? Why not simply modify alloc_smp_req() to have 
>> the required
>> alignment ? This will avoid a costly indirect function call.
> 
> Yeah, I think it's simpler to modify alloc_smp_req() directly too. 
> Yihang, Can you please cook a new one?
> 
> Thansk,
> Jason


  reply	other threads:[~2024-03-25 15:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-25 13:17 Yihang Li
2024-03-25 14:03 ` Damien Le Moal
2024-03-25 14:21   ` Jason Yan
2024-03-25 15:10     ` John Garry [this message]
2024-03-26  6:34     ` Yihang Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3ea54627-339f-4d19-896d-5843a8b9e55e@oracle.com \
    --to=john.g.garry@oracle.com \
    --cc=chenxiang66@hisilicon.com \
    --cc=dlemoal@kernel.org \
    --cc=jejb@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=liyihang9@huawei.com \
    --cc=martin.petersen@oracle.com \
    --cc=prime.zeng@huawei.com \
    --cc=yanaijie@huawei.com \
    --cc=yangxingui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®