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

RE: [PATCH for-4.17 1/2] docs: Document the minimal requirement of static heap


  • To: Julien Grall <julien@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Henry Wang <Henry.Wang@xxxxxxx>
  • Date: Fri, 14 Oct 2022 09:31:00 +0000
  • Accept-language: zh-CN, en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=2; 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=jw+mE+hCGbWjo8enhFRs1cPf2DOpUeCL5aMaK943Lmg=; b=FSh+dOtW8qBzmfPKwGuRS2Favd6Fzxt4dDHswETEx4vvEfK+21PlSSsZSCCokW1EPrtq1qHEh/YAIqCnGE1XeFhfTqIAKkaoiWpgFaZ2E6JNidz+TjaXohYknDivfE6Fn/QnBqhW/fR+S5MIwaDJb9vTowqTk+uH+eks+jhHlQusORzzgdtnPF9wfsXfP/1zsoOPHV3NjjtMvQH5o4k/QO8cllhlTT+mpTPV9UouVsToX5/2gdCa4nLNZ6WscOpEveb72AurVH13FyDM29MGlYC0vg1Vs/7WqTF8YHoK0drt5gPd0ZNjKDEV9K4KimiRTL34HBCoH4sc6maBwgWG9w==
  • 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=jw+mE+hCGbWjo8enhFRs1cPf2DOpUeCL5aMaK943Lmg=; b=gEREg+8BmAnLVch0VS8ZLgRZ3HyYb4HYnSd+jGt7mji00nCZHDkpqPcEYpO+TOi4oR7ykxuWrB2obD4M286h6pGT5GMnfQ7+YSmd1p84S4q2QfYBrfB5nq5woQMz0kaEFYKdh7bPwXLVbkFq1nKn838AnpF9CkuUxqIpxE8DwvA0Xp7fns0/05jMSnMBpm/Axjc+J5WCuPoZRIsELId3/d6PQxml+riYxkW6qk/WjyHDtMeE46jzXcRBWFlYg1ZOtNGisUEHalL43J2bz9AxzZHJ7gmEDFnacMQF+r5qJalsINuOrR3AxVZGN29rOF/DBxrqXBLFNL01DqJ3KsZHgQ==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=Sz3YIqKaEeveRotiNahZbRgZvQuWbSuE9/AMz10Edy3WACFu5clYXVaWdJorVykUY8qh5dIPOXeInnKdye9mWVCQQTO2/4WIGplojFxP3WP616DiuUrUBR1UaO20iUORikb4vypm0ewi2MoVrU8zPv+wHrXUC8De/qnHzW2aAyN7yk3w7yglm02Ai1wH7G3hnqAkENwcB42hFiENKy2FKTPO7WHxg5y0mPZCYCNwlCFqHODH5pIbJcRYx88Podckbck0malaYK9HB2pVYqtLMLdKSpkFPfwMbIohaykS2HB6bH143VCBV+LOwOAAj6qMkA7GMjxU2pNhAf0MQ5Prgw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PMeVErN05XAkl0M5YUWBE589guIfpd2PZQ3mz4e1evlKgFt789TSVCP2zDoe4IkE8OzFdVgWYJseTDkj2pap+eJ0YUnj4QKvi7vEPFZVptb2jIHRhRycy+2IZz6X4334VWrqfI9KmGl+Q7anSxPYX8UQ218u9LGIVfrlQ3JrO8/JQ2EGJmBGqMp+BYhoh1T6GvLdSlqfwEcxwO1y+Hw68xPPoBFwXhUy3EZqG2kXxPFuNUY7dB1tASAlKYAo3uEpB9VCHldGNmPq4PnPFRMajI5JhXpKUqJt1yuCqKBRcchX3RLrUo4xFjP2YNZQT1SZpVBxpSmFsODsI6LGrXAqbA==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Fri, 14 Oct 2022 09:31:16 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHY3q+bU7An58kRd0C18nD7mqtwpK4Nk9IAgAAAuGCAAAmOAIAAAGRg
  • Thread-topic: [PATCH for-4.17 1/2] docs: Document the minimal requirement of static heap

Hi Julien,

> -----Original Message-----
> From: Julien Grall <julien@xxxxxxx>
> >>> +Users should be mindful that the static heap should at least satisfy the
> >>> +allocation of the P2M maps for all guests. Currently, the minimal
> >> requirement
> >>> +of per-domain P2M pages pool is in-sync with function
> >>> +libxl__get_required_paging_memory() (for xl-created domUs) and
> >>> +domain_p2m_pages() (for dom0less domUs), that is, 1MB per vCPU,
> plus
> >> 4KiB per
> >>> +MiB of RAM for the P2M map, and plus 512KiB to cover extended
> regions.
> >>
> >> I think this wording is OK if the feature is a tech preview. However, if
> >> this is security supported, we need to provide some more details about
> >> the size.
> >>
> >> In particular, this doesn't tell a user how they can find the size that
> >> would fit them. Can this be decided with a formula?
> > My feeling of the formula would be:
> >
> > Total heap size needed per guest =  1MB * num_guest_vcpu +
> >      4KB * guest_ram_size_in_mb + 512KB +
> >      the memory allocated from heap by xzalloc/xzalloc_array for
>       various uses
> >      for example alloc_domain_struct(), d->shared_info, evtchn_bucket, etc.
> 
> There are also some pages allocated using alloc_{xen,dom}heap_pages().
> We also need to take into account runtime allocation done by some
> hypercalls (I can't remember which one) or subsystem like OPTee.
> 
> In addition to that, you also have memory for the system. E.g
> frametables, Xen page-tables, various driver allocations...
> 
> >
> > Is this formula somehow make sense to you? I think we need to have a
> > rough estimation of the last part (boot time allocation) though.
> 
> That's going to be hard. It will vary depending on your system and this
> could change in the future as we add more features. For instance, I
> expect the PCI passthrough will need some memory to keep track of all
> the devices.
> 
> I am worry the formula will become complex. Ideally we need to have a
> very simple formula. If that's not possible, then we need to provide a
> way for the user to estimate it at runtime (like what I suggested before).

I agree, I think the simple formula can only be achieved is we have an
estimation of the worst case scenario of those scattered memory usages.
I remember I once had a try so let me try to find the results back that time...

I am also very interested in the method that you proposed to provide a
mechanism for users to get the system memory allocation at runtime. But
IIUC this needs some work in another series. Could you please confirm if I
am understanding correctly? Or probably Xen has some mechanisms that
I am likely unaware? Thanks!

Kind regards,
Henry

> 
> Cheers,
> 
> --
> Julien Grall

 


Rackspace

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