From: Jan Beulich <jbeulich@suse.com> To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org> Cc: George Dunlap <george.dunlap@citrix.com>, Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org> Subject: [PATCH v2 8/8] Arm/optee: don't open-code xzalloc_flex_struct() Date: Wed, 21 Apr 2021 16:59:58 +0200 [thread overview] Message-ID: <5fa042ac-9609-eab7-b14d-a59782ef4141@suse.com> (raw) In-Reply-To: <091b4b91-712f-3526-78d1-80d31faf8e41@suse.com> The current use of xzalloc_bytes() in optee is nearly an open-coded version of xzalloc_flex_struct(), which was introduced after the driver was merged. The main difference is xzalloc_bytes() will also force the allocation to be SMP_CACHE_BYTES aligned and therefore avoid sharing the cache line. While sharing the cache line can have an impact on the performance, this is also true for most of the other users of x*alloc(), x*alloc_array(), and x*alloc_flex_struct(). So if we want to prevent sharing cache lines, arranging for this should be done in the allocator itself. In this case, we don't need stricter alignment than what the allocator provides. Hence replace the call to xzalloc_bytes() with one of xzalloc_flex_struct(). Signed-off-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Julien Grall <julien@xen.org> --- v2: Use commit message very close to what was suggested by Julien. --- a/xen/arch/arm/tee/optee.c +++ b/xen/arch/arm/tee/optee.c @@ -529,8 +529,7 @@ static struct optee_shm_buf *allocate_op while ( unlikely(old != atomic_cmpxchg(&ctx->optee_shm_buf_pages, old, new)) ); - optee_shm_buf = xzalloc_bytes(sizeof(struct optee_shm_buf) + - pages_cnt * sizeof(struct page *)); + optee_shm_buf = xzalloc_flex_struct(struct optee_shm_buf, pages, pages_cnt); if ( !optee_shm_buf ) { err_code = -ENOMEM;
next prev parent reply other threads:[~2021-04-21 15:00 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-21 14:54 [PATCH v2 0/8] assorted replacement of x[mz]alloc_bytes() Jan Beulich 2021-04-21 14:56 ` [PATCH v2 1/8] x86/MCE: avoid effectively open-coding xmalloc_array() Jan Beulich 2021-04-21 14:56 ` [PATCH v2 2/8] x86/HVM: " Jan Beulich 2021-04-21 14:57 ` [PATCH v2 3/8] x86/oprofile: " Jan Beulich 2021-04-21 14:57 ` [PATCH v2 4/8] x86/IRQ: avoid over-alignment in alloc_pirq_struct() Jan Beulich 2021-04-21 14:58 ` [PATCH v2 5/8] EFI/runtime: avoid effectively open-coding x{m,z}alloc_array() Jan Beulich 2021-04-21 14:58 ` [PATCH v2 6/8] kexec: avoid effectively open-coding xzalloc_flex_struct() Jan Beulich 2021-04-21 14:59 ` [PATCH v2 7/8] video/lfb: avoid effectively open-coding xzalloc_array() Jan Beulich 2021-04-21 14:59 ` Jan Beulich [this message] 2021-05-03 13:53 ` Ping: [PATCH v2 8/8] Arm/optee: don't open-code xzalloc_flex_struct() Jan Beulich 2021-05-04 23:49 ` Volodymyr Babchuk 2021-04-21 15:23 ` [PATCH v2 0/8] assorted replacement of x[mz]alloc_bytes() Andrew Cooper 2021-04-21 15:32 ` Jan Beulich 2021-04-23 9:44 ` Jan Beulich
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=5fa042ac-9609-eab7-b14d-a59782ef4141@suse.com \ --to=jbeulich@suse.com \ --cc=george.dunlap@citrix.com \ --cc=julien@xen.org \ --cc=sstabellini@kernel.org \ --cc=xen-devel@lists.xenproject.org \ --subject='Re: [PATCH v2 8/8] Arm/optee: don'\''t open-code xzalloc_flex_struct()' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).