[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 2/3] xen/sched: carve out memory allocation and freeing from schedule_cpu_rm()
- To: Juergen Gross <jgross@xxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 15 Aug 2022 13:52:26 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8T/K5RSB4gWzuJvP0fFBZhtL9P63/W+kn6XM/TB6dHo=; b=Gl4Av4c5wm3LaqXpixrr8Jlz+t0jqF7ooPyD36f9i6nZ5V3N8qz9yP/KhiDlgyCvJmJ99RwdA2ybjQDQR0iWnTWqwU+mYtM4IWHNrlsAZjDIGn2FGFhQZbeP9wRCc94ECtNJSl8s9I7THx3xLNrpIzECaHHUjBgKF8+DdTTY/yRnMgh6ZyCi+ttyp+oO9zM4V/CfuXco4Fr/uicrt1xvUPaKTfZnLefi5y4EnXxScZJttfwsA1EIk2ZVlH8jH4jsaWYCbryvrCgHQ0fKxFnef7Jc1zX2C4nQX0yVob9ycDNQ/0Ko5BtvvWiayAtWYefueRaSOdCxtWivPOdI5WAQug==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=irtu8H+Eqx2pq0fB20iIkcXc3biyitkTOeTMEJI8LuE9QgZ1ec6zGZOwxgA7xxuE1+LQy2GM/f4f11WtPI6eZIVNgbNSzC3YS12UPy90KeQ0v0f/kun/82rCAHE7+g3/YAMPYUg6Kd0T4XML7TFX+FPW4IfV1KrnmUrTqpxlrWUnENq6Q75e9/KNQrBa8e0+oIXuEvhSegN01l9AWb4DlUlZtbpm3w6VgVOMCjF/ZNo3D8nLmNz7nu0I1Btde2B1uFbXEtxTgMhJqEaeQVi0JAfM+jBTnFbbk3fVcPFUAs2k3Uu4gqFsViHXjrBlGKJTERX4y7l2zPwSG2YocL3vJg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: George Dunlap <george.dunlap@xxxxxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Mon, 15 Aug 2022 11:52:34 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 15.08.2022 13:04, Juergen Gross wrote:
> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -3237,6 +3237,65 @@ out:
> return ret;
> }
>
> +static struct cpu_rm_data *schedule_cpu_rm_alloc(unsigned int cpu)
> +{
> + struct cpu_rm_data *data;
> + const struct sched_resource *sr;
> + unsigned int idx;
> +
> + rcu_read_lock(&sched_res_rculock);
> +
> + sr = get_sched_res(cpu);
> + data = xmalloc_flex_struct(struct cpu_rm_data, sr, sr->granularity - 1);
> + if ( !data )
> + goto out;
> +
> + data->old_ops = sr->scheduler;
> + data->vpriv_old = idle_vcpu[cpu]->sched_unit->priv;
> + data->ppriv_old = sr->sched_priv;
Repeating a v1 comment:
"At least from an abstract perspective, doesn't reading fields from
sr require the RCU lock to be held continuously (i.e. not dropping
it at the end of this function and re-acquiring it in the caller)?"
Initially I thought you did respond to this in some way, but when
looking for a matching reply I couldn't find one.
Jan
|
