From: Dongli Zhang <dongli.zhang@oracle.com>
To: Juergen Gross <jgross@suse.com>,
xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
paul.durrant@citrix.com
Cc: wei.liu2@citrix.com, konrad.wilk@oracle.com,
srinivas.eeda@oracle.com, boris.ostrovsky@oracle.com,
roger.pau@citrix.com
Subject: Re: [Xen-devel] [PATCH 1/6] xenbus: prepare data structures and parameter for xenwatch multithreading
Date: Fri, 14 Sep 2018 21:57:55 +0800 [thread overview]
Message-ID: <45609402-c392-565b-042d-71179d982d61@oracle.com> (raw)
In-Reply-To: <23dc17b9-dc76-776b-74ef-d11f4b77552d@suse.com>
Hi Juergen and Paul,
On 09/14/2018 04:32 PM, Juergen Gross wrote:
> On 14/09/18 09:34, Dongli Zhang wrote:
>> This is the 1st patch of a (6-patch) patch set.
>>
>> This patch set of six patches introduces xenwatch multithreading (or
>> multithreaded xenwatch, abbreviated as 'mtwatch') to dom0 kernel. In
>> addition to the existing single xenwatch thread, each domU has its own
>> kernel thread ([xen-mtwatch-<domid>]) to process its xenwatch event.
>>
>> A kernel parameter 'xen_mtwatch' is introduced to control whether the
>> feature is enabled or not during dom0 kernel boot. The feature is disabled
>> by default if 'xen_mtwatch' is not set in grub. In addition, this patch
>> also introduces the data structures to maintain the status of each per-domU
>> xenwatch thread. The status of each xenwatch thread (except the default
>> one) is maintained by a mtwatch domain.
>>
>> The feature is available only on dom0.
>>
>> Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 3 ++
>> drivers/xen/xenbus/xenbus_xs.c | 31 ++++++++++++
>> include/xen/xenbus.h | 65 +++++++++++++++++++++++++
>> 3 files changed, 99 insertions(+)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 64a3bf5..fc295ef 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -4992,6 +4992,9 @@
>> the unplug protocol
>> never -- do not unplug even if version check succeeds
>>
>> + xen_mtwatch [KNL,XEN]
>> + Enables the multithreaded xenwatch (mtwatch).
>> +
>> xen_nopvspin [X86,XEN]
>> Disables the ticketlock slowpath using Xen PV
>> optimizations.
>> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
>> index 49a3874..3f137d2 100644
>> --- a/drivers/xen/xenbus/xenbus_xs.c
>> +++ b/drivers/xen/xenbus/xenbus_xs.c
>> @@ -95,6 +95,19 @@ static pid_t xenwatch_pid;
>> static DEFINE_MUTEX(xenwatch_mutex);
>> static DECLARE_WAIT_QUEUE_HEAD(watch_events_waitq);
>>
>> +bool xen_mtwatch;
>> +EXPORT_SYMBOL_GPL(xen_mtwatch);
>> +
>> +struct mtwatch_info *mtwatch_info;
>> +
>> +static bool param_xen_mtwatch;
>> +static __init int xen_parse_mtwatch(char *arg)
>> +{
>> + param_xen_mtwatch = true;
>> + return 0;
>> +}
>> +early_param("xen_mtwatch", xen_parse_mtwatch);
>
> Add a Kconfig item to set the default when building the kernel? We can
> start with default "off", but later we might want to enable this feature
> as the default.
Is there any weakness/downside configuring the param via early_param? Or is
there any strength via Kconfig?
I would prefer to not fix the configuration when building the kernel. The
administrator/user will not be able to choose the preferred option.
I would prefer to configure the option via kernel param and set default as 'off'
(false). In a common cloud environment, the administrator is only required to
enable the param in dom0/driver domain kernel.
For common domU (not using as backend), this feature is useless. I assume there
are always more domUs than dom0 (and driver domain), especially in cloud
environment.
>
>> +
>> static void xs_suspend_enter(void)
>> {
>> spin_lock(&xs_state_lock);
>> @@ -929,6 +942,24 @@ int xs_init(void)
>> if (err)
>> return err;
>>
>> + if (xen_initial_domain() && param_xen_mtwatch) {
>
> Wouldn't it be better to drop the test for xen_initial_domain() and do
> this initialization only when a caller (backend) is requesting the
> multithread mode? This would avoid wasting memory in case it isn't going
> top be used and - more important - would support driver domains.
This would save us <4KB.
Suppose the default 'param_xen_mtwatch' is 'off'. The administrator knows the
domain is used as pv backend when he/she enables the option manually.
In such scenario, is there any benefit to make it on-demand to save <4KB memory?
Thank you very much!
Dongli Zhang
>
>
> Juergen
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
>
next prev parent reply other threads:[~2018-09-14 13:58 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-14 7:34 Introduce xenwatch multithreading (mtwatch) Dongli Zhang
2018-09-14 7:34 ` [PATCH 1/6] xenbus: prepare data structures and parameter for xenwatch multithreading Dongli Zhang
2018-09-14 8:11 ` Paul Durrant
2018-09-14 13:40 ` [Xen-devel] " Dongli Zhang
2018-09-14 8:32 ` Juergen Gross
2018-09-14 13:57 ` Dongli Zhang [this message]
2018-09-14 14:10 ` [Xen-devel] " Juergen Gross
2018-09-16 20:17 ` Boris Ostrovsky
2018-09-17 1:20 ` Dongli Zhang
2018-09-17 19:08 ` Boris Ostrovsky
2018-09-25 5:14 ` Dongli Zhang
2018-09-25 20:19 ` Boris Ostrovsky
2018-09-26 2:57 ` [Xen-devel] " Dongli Zhang
2018-09-14 7:34 ` [PATCH 2/6] xenbus: implement the xenwatch multithreading framework Dongli Zhang
2018-09-14 8:45 ` Paul Durrant
2018-09-14 14:09 ` [Xen-devel] " Dongli Zhang
2018-09-14 8:56 ` Juergen Gross
2018-09-16 21:20 ` Boris Ostrovsky
2018-09-17 1:48 ` [Xen-devel] " Dongli Zhang
2018-09-17 20:00 ` Boris Ostrovsky
2018-09-14 7:34 ` [PATCH 3/6] xenbus: dispatch per-domU watch event to per-domU xenwatch thread Dongli Zhang
2018-09-14 9:01 ` Juergen Gross
2018-09-17 20:09 ` Boris Ostrovsky
2018-09-14 7:34 ` [PATCH 4/6] xenbus: process otherend_watch event at 'state' entry in xenwatch multithreading Dongli Zhang
2018-09-14 9:04 ` Juergen Gross
2018-09-14 7:34 ` [PATCH 5/6] xenbus: process be_watch events " Dongli Zhang
2018-09-14 9:12 ` Juergen Gross
2018-09-14 14:18 ` [Xen-devel] " Dongli Zhang
2018-09-14 14:26 ` Juergen Gross
2018-09-14 14:29 ` Dongli Zhang
2018-09-14 14:44 ` Juergen Gross
2018-09-19 6:15 ` Dongli Zhang
2018-09-19 8:01 ` Juergen Gross
2018-09-19 12:27 ` Dongli Zhang
2018-09-19 12:44 ` Juergen Gross
2018-09-14 14:33 ` Dongli Zhang
2018-09-14 7:34 ` [PATCH 6/6] drivers: enable xenwatch multithreading for xen-netback and xen-blkback driver Dongli Zhang
2018-09-14 9:16 ` Juergen Gross
2018-09-14 9:38 ` Wei Liu
2018-09-14 9:56 ` Roger Pau Monné
2018-09-14 8:16 ` Introduce xenwatch multithreading (mtwatch) Paul Durrant
2018-09-14 9:18 ` Juergen Gross
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=45609402-c392-565b-042d-71179d982d61@oracle.com \
--to=dongli.zhang@oracle.com \
--cc=boris.ostrovsky@oracle.com \
--cc=jgross@suse.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paul.durrant@citrix.com \
--cc=roger.pau@citrix.com \
--cc=srinivas.eeda@oracle.com \
--cc=wei.liu2@citrix.com \
--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).