linux-kernel - Re: [PATCH 0/5] optimize some data structure in nvme

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3ed34562-f366-2bb7-1a8a-e7cc9cc1c7e4@nvidia.com>
Date:   Sat, 13 May 2023 01:01:49 +0000
From:   Chaitanya Kulkarni <chaitanyak@...dia.com>
To:     Christophe JAILLET <christophe.jaillet@...adoo.fr>
CC:     "linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
        "sagi@...mberg.me" <sagi@...mberg.me>,
        Chaitanya Kulkarni <chaitanyak@...dia.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "hch@....de" <hch@....de>,
        "kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>
Subject: Re: [PATCH 0/5] optimize some data structure in nvme

On 5/1/23 05:40, Christophe JAILLET wrote:
> This serie is a proposal to slighly optimize the memory needed for some
> structures used in nvme.
>
> This follows the discussion in [1].
>
> Honnestly, I'm not convinced that this serie really brings semething.
> Because of the way memory alocation works, and its over-allocation to try to
> avoid memory fragmentation, some limited gains are most of the time useless.
>
> It could still help:
>     - many holes in structure can, at some point, have its size reach a threshold
>       (this is specially true if such structures are allocated with kcalloc() or
>       kmalloc_array())
>     - it can save some space in some other structures if embedded in them
>     - it can save a few cycles if the structure is memcpy()'ed or zeroed, for
>       example
>     - can reduce cache usage
>
> With that in mind, patch 3 is a win, patch 4 is likely a win, the other ones are
> much more theorical.
>
> The changes are really limited, so even if the gain is marginal, maybe it still
> makes sense to merge them.
>
> Each patch gives the layout generated by pahole before and after the patch.
>
> [1]: https://lore.kernel.org/all/67a9e53e-4ac9-7ba8-9713-96c1dfe1e341@nvidia.com/
>
> Christophe JAILLET (5):
>    nvmet: Reorder fields in 'struct nvmet_sq'
>    nvmet: Reorder fields in 'struct nvme_ctrl'
>    nvmet: Reorder fields in 'struct nvmf_ctrl_options'
>    nvmet: Reorder fields in 'struct nvme_dhchap_queue_context'
>    nvmet: Reorder fields in 'struct nvmefc_fcp_req'
>
>   drivers/nvme/host/auth.c       |  6 +++---
>   drivers/nvme/host/fabrics.h    |  8 ++++----
>   drivers/nvme/host/nvme.h       |  6 +++---
>   drivers/nvme/target/nvmet.h    |  4 ++--
>   include/linux/nvme-fc-driver.h | 10 +++++-----
>   5 files changed, 17 insertions(+), 17 deletions(-)
>

thanks a lot for doing this and following the comment on the other patch.

Looks good.

Reviewed-by: Chaitanya Kulkarni <kch@...dia.com>

-ck