From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "George Dunlap" <george.dunlap@citrix.com>,
"Ian Jackson" <iwj@xenproject.org>,
"Julien Grall" <julien@xen.org>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 00/11] assorted replacement of x[mz]alloc_bytes()
Date: Thu, 8 Apr 2021 16:12:47 +0200 [thread overview]
Message-ID: <8c9177fa-9909-b693-e4ee-efdfcfa51273@suse.com> (raw)
In-Reply-To: <bdb17131-2184-d8b8-a1a2-37525af02807@citrix.com>
On 08.04.2021 14:57, Andrew Cooper wrote:
> On 08/04/2021 13:13, Jan Beulich wrote:
>> In the long run I think we want to do away with these type-unsafe
>> interfaces, the more that they also request (typically) excess
>> alignment. This series of entirely independent patches is
>> eliminating the instances where it's relatively clear that they're
>> not just "blob" allocations.
>>
>>
>> 03: x86/MCE: avoid effectively open-coding xmalloc_array()
>> 04: x86/HVM: avoid effectively open-coding xmalloc_array()
>> 05: x86/oprofile: avoid effectively open-coding xmalloc_array()
>> 06: x86/IRQ: avoid over-alignment in alloc_pirq_struct()
>> 07: EFI/runtime: avoid effectively open-coding xmalloc_array()
>> 08: hypfs: avoid effectively open-coding xzalloc_array()
>> 10: video/lfb: avoid effectively open-coding xzalloc_array()
>
> The flex conversions are fine, but I am unconvinced by argument for
> interchanging array() and bytes().
>
> The cacheline size is 64 bytes, and the minimum allocation size is 16,
> plus a bhdr overhead of 32 bytes, so you're already at most of a
> cacheline for a nominally-zero sized allocation.
But you're aware that the alignment x[mz]alloc_bytes() forces is
128 bytes? Plus, while sizeof(struct bhdr) is indeed 32, the
overhead on allocated blocks is
#define BHDR_OVERHEAD (sizeof(struct bhdr) - MIN_BLOCK_SIZE)
i.e. 16 (i.e. the other half of the 32 is already the minimum
block size of 16 that you also mention). IOW a cacheline sized
block would yield 48 bytes of usable space. Specifically a
meaningful change in the PV case from what patch 06 does, where
we only need 40 bytes.
> There can however be a severe penalty from cacheline sharing, which is
> why the bytes() form does have a minimum alignment. There is one
> xmalloc heap shared across the entire system, so you've got no idea what
> might be sharing the same cache line for sub-line allocations.
This would call for distinguishing short-lived allocations (and
ones to be used mainly from a single CPU) from long-lived ones
having system wide use. I.e. a request to gain further allocation
function flavors, when already the introduction of the one new
xv[mz]alloc() has caused long-winded discussions with (so far) no
real outcome.
> We should not support sub-line allocations IMO. The savings is a
> handful of bytes at best, and some horrible performance cliffs to
> avoid. People running virtualisation are not going to be ram
> constrained to the order of a few bytes.
>
> For small allocations which don't require specific alignment, then
> putting bhdr and the allocation in the same line is fine (if we don't do
> this already), but we shouldn't be in the position of having two bhdr's
> in the same cache line, even if there are plenty of single-byte
> allocations in the theoretical worst case.
That's a request to tweak allocator internals then, not an argument
against the conversions done here.
Jan
prev parent reply other threads:[~2021-04-08 14:13 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-08 12:13 [PATCH 00/11] assorted replacement of x[mz]alloc_bytes() Jan Beulich
2021-04-08 12:16 ` [PATCH 01/11] x86/HVM: avoid effectively open-coding xzalloc_flex_struct() Jan Beulich
2021-04-08 12:20 ` Andrew Cooper
2021-04-08 12:17 ` [PATCH 02/11] x86/vPMU: " Jan Beulich
2021-04-08 12:25 ` Andrew Cooper
2021-04-08 12:29 ` Jan Beulich
2021-04-08 12:17 ` [PATCH 03/11] x86/MCE: avoid effectively open-coding xmalloc_array() Jan Beulich
2021-04-08 12:18 ` [PATCH 04/11] x86/HVM: " Jan Beulich
2021-04-08 12:19 ` [PATCH 05/11] x86/oprofile: " Jan Beulich
2021-04-08 12:20 ` [PATCH 06/11] x86/IRQ: avoid over-alignment in alloc_pirq_struct() Jan Beulich
2021-04-08 12:20 ` [PATCH 07/11] EFI/runtime: avoid effectively open-coding xmalloc_array() Jan Beulich
2021-04-08 12:21 ` [PATCH 08/11] hypfs: avoid effectively open-coding xzalloc_array() Jan Beulich
2021-04-08 14:28 ` Juergen Gross
2021-04-08 12:21 ` [PATCH 09/11] kexec: avoid effectively open-coding xzalloc_flex_struct() Jan Beulich
2021-04-09 12:54 ` Andrew Cooper
2021-04-09 13:23 ` Jan Beulich
2021-04-08 12:22 ` [PATCH 10/11] video/lfb: avoid effectively open-coding xzalloc_array() Jan Beulich
2021-04-08 12:23 ` [PATCH 11/11] Arm/optee: don't open-code xzalloc_flex_struct() Jan Beulich
2021-04-13 18:19 ` Julien Grall
2021-04-14 7:03 ` Jan Beulich
2021-04-15 10:26 ` Julien Grall
2021-04-15 11:02 ` Jan Beulich
2021-04-15 11:31 ` Julien Grall
2021-04-08 12:57 ` [PATCH 00/11] assorted replacement of x[mz]alloc_bytes() Andrew Cooper
2021-04-08 14:12 ` Jan Beulich [this message]
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=8c9177fa-9909-b693-e4ee-efdfcfa51273@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=iwj@xenproject.org \
--cc=julien@xen.org \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/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;
as well as URLs for NNTP newsgroup(s).