From: "Jürgen Groß" <jgross@suse.com>
To: boris.ostrovsky@oracle.com, linux-kernel@vger.kernel.org,
x86@kernel.org, linux-doc@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen: make multicall debug boot time selectable
Date: Mon, 8 Jul 2024 11:04:56 +0200 [thread overview]
Message-ID: <2d9ffe19-1663-499c-9699-c13ab7a341ee@suse.com> (raw)
In-Reply-To: <d28f8da5-7903-41c8-9213-4e24e376c837@oracle.com>
On 06.07.24 00:36, boris.ostrovsky@oracle.com wrote:
>
>
> On 7/3/24 7:56 AM, Juergen Gross wrote:
>
>> #define MC_BATCH 32
>> -#define MC_DEBUG 0
>> -
>> #define MC_ARGS (MC_BATCH * 16)
>> struct mc_buffer {
>> unsigned mcidx, argidx, cbidx;
>> struct multicall_entry entries[MC_BATCH];
>> -#if MC_DEBUG
>> - struct multicall_entry debug[MC_BATCH];
>> - void *caller[MC_BATCH];
>> -#endif
>> unsigned char args[MC_ARGS];
>> struct callback {
>> void (*fn)(void *);
>> @@ -50,13 +46,84 @@ struct mc_buffer {
>> } callbacks[MC_BATCH];
>> };
>> +struct mc_debug_data {
>> + struct multicall_entry debug[MC_BATCH];
>
> 'entries'? It's a mc_debug_data's copy of mc_buffer's entries.
Yes, this is better.
> Also, would it be better to keep these fields as a struct of scalars and instead
> have the percpu array of this struct? Otherwise there is a whole bunch of
> [MC_BATCH] arrays, all of them really indexed by the same value. (And while at
> it, there is no reason to have callbacks[MC_BATCH] sized like that -- it has
> nothing to do with batch size and can probably be made smaller)
As today the mc_buffer's entries are copied via a single memcpy(), there
are 3 options:
- make mc_debug_data a percpu pointer to a single array, requiring to
copy the mc_buffer's entries in a loop
- let struct mc_debug_data contain two arrays (entries[] and struct foo {}[],
with struct foo containing the other pointers/values)
- keep the layout as in my patch
Regarding the callbacks: I think the max number of callbacks is indeed MC_BATCH,
as for each batch member one callback might be requested. So I'd rather keep it
the way it is today.
>> + void *caller[MC_BATCH];
>> + size_t argsz[MC_BATCH];
>> +};
>> +
>> static DEFINE_PER_CPU(struct mc_buffer, mc_buffer);
>> +static struct mc_debug_data __percpu *mc_debug_data;
>> +static struct mc_debug_data mc_debug_data_early __initdata;
>
> How about (I think this should work):
>
> static struct mc_debug_data __percpu *mc_debug_data __refdata =
> &mc_debug_data_early;
>
> Then you won't need get_mc_debug_ptr().
I like this idea.
Juergen
next prev parent reply other threads:[~2024-07-08 9:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-03 11:56 [PATCH] xen: make multicall debug boot time selectable Juergen Gross
2024-07-05 22:36 ` boris.ostrovsky
2024-07-08 9:04 ` Jürgen Groß [this message]
2024-07-08 14:32 ` boris.ostrovsky
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=2d9ffe19-1663-499c-9699-c13ab7a341ee@suse.com \
--to=jgross@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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