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

Re: [PATCH v2 6/7] xen/arm: Implement the logic for static shared memory from Xen heap


  • To: Luca Fancellu <Luca.Fancellu@xxxxxxx>
  • From: Michal Orzel <michal.orzel@xxxxxxx>
  • Date: Mon, 20 May 2024 15:13:34 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • 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=Bjj6UaZejEdBGuyqu/WcFnlnU49Zl3j4wbcK49I1K68=; b=Bv7a3ZgruAwnsK1fp73UQHGRV3wHckRtsw99DTJCOdKmfHDDTKvGZOKhx1yXpvpdxBOktMgEm72JolWm+JCPqVqZn0UadG61mNFoTasMcX257poCBRl+5wuNTUHbOd3weKuo7Zqgk+sdaWvqTPKb6el5pm6e9UfmaK+lfUL9nxNF8PDm9Ya5PFOjLHW3b9/QwsJQ5mgkIfQaS2yGQg81bC/VL9Rg1rWQ3P6sItYmvDPbGzvvkT42zjGJF/82VycjdxLd3qHyBcKaIpBfbgbHYLEr2ZHrxW0MmIyGsiI5pBRudTt1NxwHMYtpPV5EMpMFz+ON6hacMm6qKntwLAs/dQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TSkZakAmVIB7plj/gRBeK3tDwRmKL5x6ww7/DsPLJWKV0bH8yUcEfxCq/4yKdVgtCglzzElbA8KIIG6L4mBKoyvGsdL0vqfudkUhb12ItmvNzb8xemxT7FvO2P/h8Wz1Ul8zCdNXygSXfx7hYMMpqqzOeeN1XH/2OPEJoq12KougqTgdYUZjrNhpvTDy8c5eKGpLB3ohx4Yrs5UgnngZZ7JDfRBqwKhAsRSJid3VXwCfTLw7s9C80PFaLzDPmFuTf2uu0PQrL6R+9s1RZEQwjaC052eYX95jFLR+mzYw7AwHSR4FbLx/9fahi05xwZZYYhALMJImSmqmMNXykiapkQ==
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Mon, 20 May 2024 13:13:54 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


On 20/05/2024 15:11, Luca Fancellu wrote:
> 
> 
>>>
>>>>
>>>>> +    struct shmem_membank_extra *bank_extra_info;
>>>>> +} alloc_heap_pages_cb_extra;
>>>>> +
>>>>> +static struct meminfo __initdata shm_heap_banks = {
>>>>> +    .common.max_banks = NR_MEM_BANKS
>>>> Do we expect that many banks?
>>>
>>> Not really, but I was trying to don’t introduce another type, do you think 
>>> it’s better instead to
>>> introduce a new type only here, with a lower amount of banks?
>> I'd be ok with meminfo provided you add a reasoning behind this being 
>> meminfo and not shared_meminfo.
>>
>>>
>>> Because if we take struct shared_meminfo, we would waste mem for its 
>>> ‘extra’ member.
>> Would it result in a smaller footprint overall?
> 
> Well overall yes, meminfo now is 255 banks, shared_meminfo is 64 in total, 
> even if we use 32 of them and
> 32 are wasted.
> 
> Otherwise, as I said, I could do something like this in this module:
> 
> static struct shared_heap_meminfo {
>     struct membanks_hdr common;
>     struct membank bank[NR_SHMEM_BANKS];
> } __initdata shm_heap_banks = {
>     .common.max_banks = NR_SHMEM_BANKS
> };
If that's all it takes to avoid defining unnecessarily big variable, then I'd 
be ok with it.

~Michal



 


Rackspace

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