Re: [PATCH RFC 2/3] xen/domain: add domain hypfs directories

["Jürgen Groß" <jgross@suse.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2378 bytes --]

On 09.12.20 17:37, Julien Grall wrote:
> Hi Juergen,
> 
> On 09/12/2020 16:16, Juergen Gross wrote:
>> Add /domain/<domid> directories to hypfs. Those are completely
>> dynamic, so the related hypfs access functions need to be implemented.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> V3:
>> - new patch
>> ---
>>   docs/misc/hypfs-paths.pandoc |  10 +++
>>   xen/common/Makefile          |   1 +
>>   xen/common/hypfs_dom.c       | 137 +++++++++++++++++++++++++++++++++++
>>   3 files changed, 148 insertions(+)
>>   create mode 100644 xen/common/hypfs_dom.c
>>
>> diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
>> index e86f7d0dbe..116642e367 100644
>> --- a/docs/misc/hypfs-paths.pandoc
>> +++ b/docs/misc/hypfs-paths.pandoc
>> @@ -34,6 +34,7 @@ not containing any '/' character. The names "." and 
>> ".." are reserved
>>   for file system internal use.
>>   VALUES are strings and can take the following forms (note that this 
>> represents
>> +>>>>>>> patched
> 
> This seems to be a left-over of a merge.

Oh, interesting that I wasn't warned about that.

> 
>>   only the syntax used in this document):
>>   * STRING -- an arbitrary 0-delimited byte string.
>> @@ -191,6 +192,15 @@ The scheduling granularity of a cpupool.
>>   Writing a value is allowed only for cpupools with no cpu assigned 
>> and if the
>>   architecture is supporting different scheduling granularities.
> 
> [...]
> 
>> +
>> +static int domain_dir_read(const struct hypfs_entry *entry,
>> +                           XEN_GUEST_HANDLE_PARAM(void) uaddr)
>> +{
>> +    int ret = 0;
>> +    const struct domain *d;
>> +
>> +    for_each_domain ( d )
> 
> This is definitely going to be an issue if you have a lot of domain 
> running as Xen is not preemptible.

In general this is correct, but in this case I don't think it will
be a problem. The execution time for each loop iteration should be
rather short (in the microsecond range?), so even with 32000 guests
we would stay way below one second. And on rather slow cpus I don't
think we'd have thousands of guests anyway.

> I think the first step is to make sure that HYPFS can scale without 
> hogging a pCPU for a long time.

I agree this would be best.


Juergen


[-- Attachment #1.1.2: OpenPGP_0xB0DE9DD628BF132F.asc --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]