[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 1/2] xen/memory : Add stats_table resource type


  • To: Matias Ezequiel Vara Larsen <matiasevara@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 22 Jun 2022 10:59:50 +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=8wUJM8J/QKOFelvYOIxKZZT3Bd4+jlhw35Xmbg0vNTU=; b=eAbVCJlColhfC7GbQ0bzXma+BUwTJ8IOUM2djmXhl1v6+mz+mv1UqEmNpucEFPpIHhpck307vCLh+4GnnSXvBAlnDEdpVYRVtlhLoNbe03XYAJA1IIQIEJIPdQ/RCBWdj7ES16UekZBmIKyD83AvJ2s6Y/BdvlPzbVmEop4t7jdskI/KoJ3+kS0EZMfQS0Bqjn2QXZDXi4z7y4rlRCFXuegSq8Wz5114jCbtCQhWkSshPGRzlQa2bsGxvUSRtqWOL9H+K6PxUkvnsskzYjKLMk1GzIIPXGho0p3zk2EnVzruzZL8ct3oglY/wiVehXVChKula1QVc1xYwS+5YGQN1g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dlg7K0R+NqwjEUa0jik9ZZ7vz9vsWoOWKLI336HZnwbeGLiWCvdJS/6xySRu9T/uWIrKXu0HACV+IGQ7Cb0OGpf4zUh6SccrSML4G3Oi0vBhne0pOYoMq4e8imUsAYLRQVpQvjDLSoIrk/WDDJmvFm584B4lVPRuKVNf5U0EaU1HvHwuKpHaP7+uAggjxda/4VD9VS++0GnHGbCjN/k1+GXwVHmTZ5Sz2KOkTwgO5WwA3C7VSLYAOUbnoemvav0exaX6cOflgMB/+hKo++K9QYGP+jqpLRcWwIxzJCCfXHSphpn5iXDofPy43AhPHvJnZTsEEtH16K4DGWK2/m70qw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Matias Ezequiel Vara Larsen <matias.vara@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 22 Jun 2022 09:00:04 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 17.05.2022 16:33, Matias Ezequiel Vara Larsen wrote:
> @@ -287,6 +288,10 @@ static inline void vcpu_runstate_change(
>      }
>  
>      v->runstate.state = new_state;
> +
> +    // WIP: use a different interface
> +    runstate = (uint64_t*)v->stats.va;
> +    memcpy(runstate, &v->runstate.time[0], sizeof(v->runstate.time[0]));
>  }

One remark on top of what George has said: By exposing this information the
way you do, you allow updating and reading of it to be fully asynchronous.
That way a consumer may fetch inconsistent (partially updated) state (and
this would be even more so when further fields would be added). For the
data to be useful, you need to add a mechanism for consumers to know when
an update is in progress, so they can wait and then retry. You'll find a
number of instances of such in the code base.

In general I also have to admit that I'm not sure the exposed data really
qualifies as a "resource", and hence I'm not really convinced of your use
of the resource mapping interface as a vehicle.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.